SEI Ad Audit Ping

Engineering Portal / Digital / Digital Ad Ratings / SEI Ad Audit Ping

Introduction

The Nielsen Server-to-Server (S2S) solution needs audit pings for audience validation. The audit pings are https requests that are fired at least once per session. It primarily contains URL parameters with a randomly generated Session Identifier, Integration Identifier, and a timestamp that is matched to the server-side traffic.

The end user device makes a request to Nielsen Collections servers at least once per Session. Sessions are defined as continuous interaction with the application, as defined by the Publisher. The Audit pings are executed ideally at the beginning of the Session or upon first ad exposure. Audit Pings may optionally fire more often, for example: fired upon each ad exposure if preferred.

Audit Pings are intended to be as light-weight, generic as possible, and contain no personal identifiers, campaign information, or advertisement metadata.

Ping Structure

Requests should be executed with the following convention structure:

https://audit.imrworldwide.com/cgi-bin/gn?prd=audit&+[query parameters]

(Please note that this URL may require updates in response to changes in the market.)

The Audit Ping will carry all parameters in the matrix later in this document. Under normal operating circumstances, the Nielsen collection system will return the following response codes:

• 302: A redirect to another Nielsen domain, used for the purpose of generating a URL compatible with Nielsen streaming meters
• 200: The ping was successfully received, inspect traffic to ensure no CORS error

Audit Ping Implementation Details

• SessionID is ideally generated when the application is initiated, optionally upon first ad exposure
• Audit Pings should be executed at least every time a SessionID is created
• It is permissible for Audit Pings to fire more frequently than once per session (for example, upon each ad exposure, or page change, etc.)
• It is permissible for SessionIDs to change within a session, so long as the Audit Ping is fired again ensuring that the ImpID parameter reflects the same new SessionID
• For security reasons, downstream servers reject cross-origin HTTP requests with preflight. To ensure that audit ping requests are accepted, allowable Content-Types like "text/plain" in simple GET requests ensure that preflight requests are not invoked, which is the preferred behavior.

Relay Audit Ping (Server to Server)

The relay audit ping is an alternative to the standard audit ping, which is more privacy friendly, since it does not require direct calls from the user client device to the Nielsen backend. It also allows partners to mask XFF (X-Forwarded-For) /24 (IPv4) or /48 (IPv6) as well as control HTTP Client Hints. This can however limit Nielsen’s ability to enrich the collected data using geo resolution, device classification and GIVT, if the partner chooses to severely limit or filter completely the original client IP and User Agent. As a result the implementation of relay audit ping may require additional characteristics to be sent via the exposure logs in order to compensate for the loss of signal. For more details please refer to the Viewing Spec. The relay audit ping is implemented using a two legged approach described below. The additional pairing ping becomes necessary, since relayed audit ping cannot be used to redirect the user client for panel matching purposes.

1. Pairing Ping. This is an end-user-device-initiated ping with partner-owned root domain and SessionID included in subdomain. It is used for panel matching. Nielsen meters will be trained to recognize the unique domain format. Example: https://2576459933726989.darnuid.[publisher-domain].com
2. Relay Audit Ping. This is an end-user-device-initiated audit ping relayed by the partner's backend (via proxy server) with furnished URL parameters outlined below. Example: https://audit.imrworldwide.com/cgi-bin/gn?prd=audit&intid=fgrclqou0dzb1u4jq2jecoyvza&apid=FCGG4EC1-E0f4-B465-Ef40-070AAD3173A1&sessionid=2576459933726989&product=dtvr&createtm=1643858542

Query Parameters

Parameter	Description	Mandatory?	Specified By	Format Example
intid	Single ID assigned per integration for all audit pings across platforms	Yes	Nielsen	a9ddf15ea054ea415718767ea6
apid	Server App ID assigned by Nielsen	Only required for content measurement	Nielsen	Alphanumeric application identifier assigned by Nielsen by platform
sessionid	Unique id generated when video player is instantiated	Yes	Client	Format: alphanumeric, Example: 16 char guid
product	Indicates which product audit ping content corresponds to	Yes	Client	Format: alphanumeric, Example: “dar”, “dcr”, “dtvr”
createtm	Time the ping was fired	Yes	Client	Format: UnixTime “1643858542”

Generic Ping Format:

https://audit.imrworldwide.com/cgi-bin/gn?prd=audit&intid=<Integration id>&apid=<App id>&sessionid=<Session Id>&product=<dar>&createtm=<>

Audit Ping Example:

https://audit.imrworldwide.com/cgi-bin/gn?prd=audit&intid=a9ddf15ea054ea415718767ea6&apid=FC984EC1-E044-B465-E040-070AAD3173A1&sessionid=2576459933726989&product=dar&createtm=1643858542

Nielsen One Ads Impression Implementation Details

A new Impression ID parameter specified as "&impid" that exactly matches the SessionID included in the Audit Pings.

Example Nielsen One Ads Ping:

https://secure-us.imrworldwide.com/cgi-bin/m?ci=us-201234h&cg=0[...]&impid=2576459933726989&rnd=164403011

Supported IP and UA attributes and their order of precedence:

IP Address Attributes	UA String Attributes
Query String -> &clientip	HTTP Header -> X-Device-User-Agent
Query String -> &ip	HTTP Header -> User-Agent
HTTP Header -> X-Forwarded-For (left most ip)
TCP connection socket