• Создана пользователем Неизвестный пользователь (sergey). Последнее обновление: дек. 22, 2015 Время чтения: 2 мин.

Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 10 Следующий »

Revisions history

RevisionChanges
1.

Initial version

1.1Changed 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

  • Нет меток