Server-to-Server App Install Specification v2.1

This specification describes the new Server-to-Server app install integration with Native & Search. The spec is intended for 3rd Party Mobile Measurement Providers (3PMMP) who wish to integrate with Native & Search via S2S, and is aimed at Data Providers like Kochava, Tune, AppsFlyer, Adjust, Apsalar, CyberZ/FOX and others.

The goal of this effort is to eliminate the use of client-side tracking URLs for app install conversions, and provide faster, more reliable conversion tracking for Native & Search 3rd Party Data Providers.

Third-party Data Providers are encouraged to take advantage of this spec and use it to code up for improved app install and in-app event integration.

For information about in-app event integration, refer to the Server-to-Server In-app Events Specification v1.0.


Support is only provided for one SDK attribution partner per app at this time.


Once 3rd Party Data Providers are familiar with the spec, Oath will do the following:

  1. Generate an authentication key, provided in a password protected zip file. The password will be provided verbally from your Oath contact.
  2. As a Data Provider, you will implement this request:
<endpoint_cname> =

Test Phase 1

Follow these steps:

  1. Oath will provide you with mobile ids for iOS and Android, which you can use for testing during Phase 1.
  2. As a Data Provider, you will send a call to the production endpoint with the those ids.
  3. Yahoo will verify the request.
  4. You should then validate the response.

Test Phase 2

Follow these steps:

  1. Switch traffic on production for 1 hour.
  2. Confirm that you will not be sending the post-backs to the legacy endpoint during the 1-hr test. This will prevent duplicate conversions.


Migration (optional). For Data providers who are currently using the click method, a migration process will be discussed. If possible, a hard cut-off time is preferred for simplicity.

Typical Workflow

This is the workflow sequence that occurs when the user who clicks on an ad, the Data Provider receives a call and Yahoo tries to attribute the app install:

  1. A user clicks an ad, downloads an app, and opens the app.
  2. The Data Provider receives a call from the app with specific details.
  3. The Data Provider populates the JSON request below with the required details. Note that all installations will need to be sent.
  4. Oath tries to attribute the install.
  5. If Oath can match the installation, the response will contain the claim attribute with the appropriate information.
  6. If not, the request will be returned without a claims attribute.


Make this request:


Specify this as your endpoint:

<endpoint_cname> =

Signature Calculation

Note that the bs parameter must be passed as the first query parameter. This string parameter is an HMAC SHA-256 in HEX format signature of the request string, starting from /appinstall? until the end of string, excluding bs-<sig>.

For example:


Use the authentication key provided to you in order to generate the signature.

Signature Calculation Example

Request URL:

String to be signed:


Sample authentication key: abcde1234

The calculated signature from the example:


Fields for Install Events Endpoint

The following fields are for this endpoint:

<endpoint_cname> =
Fields Type Description
bs string This is an HMAC SHA-256 in HEX format signature of the request string, starting from /appinstall? until the end of the string, excluding bs=<sig>.
dp string Id of the 3P data providers for identification to Native & Search.
id string Request’s globally unique identifier (GUID), for debugging/troubleshooting.
ai string App store id: 9-digit numeric id for iTunes, package name for Android.
mi string IDFA / advertising id.
it integer App first time launch time, in milliseconds.
ir string

Google install referrer value, without filtering.

For example:


ua string

Key-value pairs of user agent identifying information.

Format: a url-encoded list of key-value pairs with the following delimiters:

‘;’ delimeter between key-value pair ‘=’ delimiter between a key and a value

Example: &

See details on the supported keys in the table below.

ip string
ipv6 string 2001%3Adb8%3A85a3%3A8d3%3A1319%3A8a2e%3A370%3A7348

Response JSON Schema

All fields listed below should be supported and consumed by the 3P data provider. Fields that are marked as optional, may or may not be sent in the response based on internal Yahoo availability.

        "original_request": "string",
        "claims": {
                "type": "array",
                "items": {
                        "type": "object",
                        "properties": {
                                "timestamp_ms": {
                                        "type": "integer"
                                "event_type": {
                                        "type": "integer"
                                "creative_id": {
                                        "type": "integer"
                                "creative_name": {
                                        "type": "string"
                                "adgroup_id": {
                                        "type": "integer"
                                "adgroup_name": {
                                        "type": "string"
                                "campaign_id": {
                                        "type": "integer"
                                "campaign_name": {
                                        "type": "string"
                                "advertiser_id": {
                                        "type": "integer"
                                "advertiser_name": {
                                        "type": "string"
                                "site_id": {
                                        "type": "string"
                                "ip_address": {
                                        "type": "string"
        "network_id": {
                    "type": "string"

Response JSON Example

     "original_request": "http://",
     "claims": [{
             "timestamp_ms": 1445539353000,
             "event_type”: 200,
             "creative_id": 1923847162,
             "creative_name": “creative name",
             "adgroup_id": 1324182736,
             "adgroup_name": “ad group name",
             "campaign_id": 302934875,
             "campaign_name": “campaign name",
             "advertiser_id": 908733,
             "advertiser_name": “advertiser name",
             "site_id": "dhjs8723tgajshd23a",
             "ip_address": "",

  "network_id": "9128376dhfgasd"

Response field types and descriptions are shown in the table below.


All fields listed below should be supported and consumed by the 3P data provider. Fields that are marked as optional, may or may not be sent in the response based on internal Yahoo availability.

Field Type Description Comments
original.request string Original app install request from 3P Data Provider.  
claims.timestamp_ms integer Event timestamp, in milliseconds.  
claims.event_type integer

Event type:

100 = impression 200 = click

claims.creative_id integer Native & Search creative (ad) id.  
claims.creative_name string Native & Search creative (ad) name.  
claims.adgroup_id integer Native & Search ad group id.  
claims.adgroup_name string Native & Search ad group name.  
claims.campaign_id integer Native & Search campaign id.  
claims.campaign_name string Native & Search campaign name.  
claims.advertiser_id integer Native & Search advertiser id.  
claims.advertiser_name string Native & Search advertiser name.  
claims.ip_address string client IP address.  
claims.demand_platform_id integer Id to allow measurement partner to determine which Oath demand platform served the claim. Note that 1 is for Native & Search, 2 is for BrightRoll DSP.
claims.campaign_type string Used to share different campaign objectives to 3P. Note that this is for App Install or Reengagement campaigns.
network_id string Id to identify Native & Search to 3P Data Providers. Note that is an optional field.

Partner Integration for GDPR

Requirements to continue running any Oath ad campaigns.

One of the two following things must be done prior to May 1st, 2018 to continue working with Oath in any capacity:

  • All events sent to Oath must include IP address. This will allow Oath to determine user jurisdiction and treat data appropriately.
  • Alternatively, partners can implement the IAB GDPR consent and pass Oath consent of the user.

Each partner must pass IP address on all installs/in-app events in addition to device ID.  This will allow Oath to determine user jurisdiction when responding to all claims and respond appropriately in cases where Oath does not have consent per regulations of that user’s jurisdiction. After May 1st, 2018, any partner who has not implemented this will have their integrations shut down globally.

Alternatively, partners can implement the IAB GDPR consent and pass Oath consent of the user.

Requirements to continue running Oath EU campaigns

To continue measuring Oath campaigns in the EU, each partner must complete the following by May 1st, 2018. Partners failing to meet these requirements by May 1st will no longer receive any data from Oath for EU campaigns until these requirements are met. Oath will communicate to advertisers which partners have or have not completed this integration in order to set expectations on which campaigns can be ran in the EU.

  • Each partner must integrate with Oath’s processor API. This is how Oath will inform partners of Oath users invoking their data subject rights granted to them under GDPR.
  • Each partner must sign a contract to commit to Oath that they will implement all aspects of GDPR in good faith, including deleting any data received from Oath when the processor API instructs them to do so.