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 segmented data to RTBSuite DSP for further targeting. The workflow is as follows:
- DMP uploads data through SFTP protocol on RTBSuite servers
- The data is represented as set of txt.gz files using tab separated format (below)
- DSP starts using this data
File name format
The data should be stored in txt.gz files in following format:
[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:
the_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
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 |
Cookie (user) matching
For matching DSP and DMP user ids DMP should support user matching aligned with GetIntent DSP API. Depending of which side initiates matching/initiates syncs different workflows is applied. See table below:
| DSP Initiates Syncs | DMP Initiates Syncs |
DMP Stores Matching | DSP calls:
//dmp_url?...[DSP_USER _ID]
DMP Stores Match | DMP calls
//px.adhigh.net/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:
//px.adhigh.net/p/cm/
[DMP_NAME]?u=[DMP_USER_ID]
DSP Stores Match | DMP calls
//px.adhigh.net/p/cm/
[DMP_NAME]?u=[DMP_USER_ID]
DMP Stores Match |
By default GetIntent will support only DMP-side matching storage and both sync initiation options