Просмотреть исходный

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 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:

	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

By default RTBSuite will support only DMP-side matching storage and both sync initiation options