Skip to main content

Attribute Sync Service

Introduction

The Data Sync Service offers implementers the option to store items on the Adhese server, which can be used for inventory, campaign insights, and targeting. The storage can be linked to any kind of identifier as per configuration.

Server Side Memory

The memory service allows an implementer to save certain data points linked to a unique key. The key can be either a user ID, which is only allowed with explicit consent from the user, or any other non-personal key (e.g., a DOOH device ID).

The event is a string that will be saved and reported exactly as sent in. It can be completed with a human-readable label in the Adhese inventory configuration.

The third parameter of the memory service is optional and indicates the time-to-live of the saved data point. When no value is passed, the default of 14 days will be applied.

https://ads-[customer].adhese.com/usersync/handlers/[service_handler]/user_sync?id=[event1],[event2]&u=[userid]&ttl=[expiration_in_minutes]

Example

https://ads-[customer].adhese.com/usersync/handlers/ec_view/user_sync?id=pricewatch&u=123abc&ttl=20160

Example with multiple events

https://ads-[customer].adhese.com/usersync/handlers/ec_view/user_sync?id=pricewatch,laptop,macbook&u=123abc&ttl=20160

Removing Data for a Key or User

All data stored in Redis will expire after a given time. However, for multiple reasons, the 'right to be forgotten' is one of the most important ones, and it is also necessary to provide a way to remove the stored data at the request of the rights holder (the end-user).

For this purpose, you can simply call the user sync service with the user ID or key you want the data removed for. The service will remove all data stored for that key and then remove the key itself.

Example

https://ads-[customer].adhese.com/usersync/handlers/ec_view/user_sync?iu=123abc

User sync for Open Market OpenRTB

A very specific application of the Data Sync Service can be used to support the OpenRTB User Sync process.

The User Sync process attempts to match P users with SSP users. We recommend syncing users once every day at the first opportunity.

The User Sync service is triggered by Adhese directly on the client and allows the SSP to connect to the client and pass the resulting user ID to Adhese.

According to the setup, a simple or complex workflow is available. The complex workflow leads to a 1st party user sync cookie, while the simple workflow leads to a 3rd party user sync cookie.

User Consent: This application of the sync service depends on a cookie that contains a unique ID. Users need to be informed about this and give consent prior to calling the service. Adhese has the contractual right to audit the use of this service to ensure it is legally implemented.

Simple workflow

  1. The user navigates to newz.zz

  2. Browser calls SSP endpoint https://ssp.com/sync?partner=adhese

  3. The SSP redirects to the user sync endpoint

  4. Browser calls Adhese user sync endpoint https://user-sync.adhese.com/handlers/ssp/user_sync?u=IH3D8DXL-20-KV8Y

  5. We issue a cookie Set-Cookie: ssp_uid=IH3D8DXL-20-KV8Y; Domain=.adhese.com; Expires=Fri, 25-Dec-2024 09:57:40 GMT; Path=/

  6. Browser requests an ad on https://ads-adhese.com/ad/sl_foo_-bar

  7. We read ssp_uid cookie to send it over to the SSP’s API

Complex workflow for 1st domain implementations

It's more complicated if a publisher serves on its own domains; no calls are made to *.adhese.com

  1. The user navigates to publisher-domain.com

  2. Browser registers request domain with Adhese user sync discovery https://user-sync.adhese.com/handlers/ssp/user_sync_discovery?domain=adhese.publisher-domain.com&protocol=https

protocol query parameter is optional, it defaults to https

  1. We read the domain parameter

  2. We issue a cookie: Set-Cookie: user_sync_domain=adhese.publisher-domain.com;Path=/;Expires=Fri, 25-Dec-2024 10:16:23 GMT

  3. The browser calls the SSP endpoint https://ssp.com/sync?p=publisher

  4. SSP redirects to user sync discovery

  5. The browser calls Adhese user sync discovery https://user-sync.adhese.com/handlers/ssp/user_sync_discovery?u=IH3D8DXL-20-KV8Y

  6. We read the user_sync_domain cookie

  7. We redirect the call to the user sync endpoint running on the correct domain

  8. The browser calls Adhese user sync endpoint https://adhese.publisher-domain.com/handlers/ssp/user_sync?u=IH3D8DXL-20-KV8Y

  9. We issue a cookie: Set-Cookie: ssp_uid=IH3D8DXL-20-KV8Y; Expires=Fri, 25-Dec-2024 09:57:40 GMT; Path=/

  10. Browser requests an ad on https://adhese.publisher-domain.com/ad/sl_foo_-bar

  11. We read the ssp_uid cookie to send it over SSP’s API

Back to top