Revisions history
| Revision | Changes |
|---|
| 1. | Initial version |
| 1.1 | Changed mobile DMP USER ID raw and md5 formats and hashing rules. |
Basics
This document describes a generic way to upload DMP segments to RTBSuite DSP. The workflow is as follows:
- DMP uploads data (TSV gzipped files with headers) through SFTP protocol on RTBSuite servers
- RTBSuite starts using segments data for targeting
File name format
DMP data should be stored in txt.gz files and be named the following way:
[DMP ID].[DATE as yyyy-MM-dd_HH-mm-ss].[FILE ID].txt.gz
Where:
- [DMP ID] a string id assigned to DMP partner
- [DATE] date of file generation in specified format
- [FILE ID] unique file id
Example:
some_dmp. 2015-07-15_12-00-00.632a0017-bbda-4be7-a5fe-6a2478b65c89.txt.gz
Data format
The first line of file should be a header and will always be ignored. The further line should follow the syntax below:
[DMP USER ID]<tab>[DSP USER ID]<tab>[SEGMENTS TO ADD]<tab>[SEGMENTS TO REMOVE]
Where:
- [DMP USER ID] – DMP user id (could be empty)
- [DSP USER ID] – DSP user id (could be empty)
- [SEGMENTS TO ADD] – comma separated list of segments. Each segments should be an id or id:expiration timestamp (in UTC/milliseconds). Example "1,2,3" or "1,3,4: 1437061152368". If expiration time isn't given for segment a default expiration policy (configured per DMP) will be applied
- [SEGMENTS TO REMOVE] – comma separated list of segments
Notes:
- Only one of [DMP USER ID] or [DSP USER ID] should present (depends on which party is storing user matching tables)
User ID format
For display (desktop inventory format) [DMP USER ID] or [DSP USER ID] could be any string that doesn't contain ':' character.
For mobile DMP USER ID each user id should have a prefix
Prefix | Meaning | Examples |
|---|
m_raw | Raw advertiser id
(iOS IDFA or Android Advertising ID). Case sensitive | Android
m_raw:dec820aa-41ae-43e0-b3b1-19e2ab258233
iOS
m_raw:C78B8B75-885A-4573-B394-CEB5B1337BA3 |
m_md5 | MD5 hash of IDFA or Android ID. Hashing is done over string representation of UUID! After that hash is encoded to hex string.
NOTE: md5 hashing is compatible with google AdX hashing | m_md5: 86d8638a89ae4a53a57746500f268bcc
(hash of dec820aa-41ae-43e0-b3b1-19e2ab258233)
m_md5: d03b31165b28e930419700bcba1cd7ab
(hash of 0AAF2E9B-8237-66FE-4768-35EF193327CA)
m_md5: 95a3c8be285dcb7b83a4a76f3bf4a4f6
(hash of 7D50A078-3388-8161-AC55-FFE718377953) |
m_sha1 | NOT SUPPORTED | NOT SUPPORTED |
User matching flow
RTBSuite can store user matching tables on their side but it's no recommended and should be done only in case it's the only option to integrate with DMP. The following matching cases are supported:
| DSP Initiates Syncs | DMP Initiates Syncs |
|---|
DMP Stores Matching | DSP calls:
//dmp_url?...[DSP_USER _ID]
DMP Stores Match | DMP calls
//[RTBSuite domain]/p/cm/[DMP_NAME]?u=[DMP_USER_ID]
DSP Redirects to:
//dmp_url?...[DSP_USER _ID]
DMP Stores Match |
DSP Stores Matching | DSP calls:
//dmp_url?...[DSP_USER _ID]
DMP Redirects to:
//[RTBSuite domain]/p/cm/[DMP_NAME]?u=[DMP_USER_ID]
DSP Stores Match | DMP calls
//[RTBSuite domain]/p/cm/[DMP_NAME]?u=[DMP_USER_ID]
DMP Stores Match |