...
This document describes a generic way to upload segmented data DMP segments to RTBSuite DSP for further targeting. The workflow is as follows:
- DMP uploads data (TSV gzipped files with headers) through SFTP protocol on RTBSuite servers
- The data is represented as set of txt.gz files using tab separated format (below)
- DSP RTBSuite starts using this segments data
...
- for targeting
File name format
The DMP data should be stored in txt.gz files in following formatand 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:
thesome_dmp. 2015-07-15_12-00-00.632a0017-bbda-4be7-a5fe-6a2478b65c89.txt.gz
...
- 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 | Android |
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. | m_md5: 86d8638a89ae4a53a57746500f268bcc |
m_sha1 | NOT SUPPORTED | NOT SUPPORTED |
...
User matching flow
RTBSuite can keep 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:
For matching DSP and DMP user ids DMP should support user matching aligned with RTBSuite 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 calls |
DSP Stores Matching | DSP calls: | DMP calls |
...