How to deal with discrepancy?

#BlogPost

UBIDEX starts post series that can help industry players answer the "how-to" questions. We will consider the hottest business and tech cases that have already turned into the best practices. There are still blind spots that need to be reviewed in programmatic, especially when it comes to payouts. This is the case of discrepancy. There have been no industry players who don't face this problem.
This blog post we devote to one of the biggest challenges which is faced every day - DISCREPANCY.

What is discrepancy?

Ad discrepancy is the difference in analytical data between two parties. Reporting discrepancies are common and expected when multiple systems are used to measure line item delivery.

Illustration

Typically, discrepancy of up to 10% can be acceptable; however, at times they can reach 20% and more. There are many different reasons why discrepancy occurs.
For example, counting methodologies can differ between parties, as each party can potentially count an impression at a slightly different point in the delivery of an ad.
There is a way to decrease discrepancy during the stage of configuring the Publisher endpoint. Follow each step before making the endpoint live.

Step 1: configure endpoint (EP) for publisher before making it live

● Negotiate with the publisher by which numbers you are going to payout them and terms of payments. Preferably to work on your numbers.
● Provide the publisher with a Statistic API URL so they can pull the stats from the platform and monitor if there is a discrepancy between your and their numbers.
● Ask the publisher to provide their Statistic API URL and insert it under the Publisher account with START_DATE, END_DATE macros to be able to monitor what they count and troubleshoot instantly.
● Discuss with the publisher which communication protocol you are going to work through (OpenRTB, XML, JSON). In the case of OpenRTB, they should specify a version of the protocol.
● Ask the publisher where they have their data centers located.
● Ask the publisher if they have an integration document with examples of the supported OpenRtb requests/responses for all ad types you are going to work with.
● Provide the publisher with your requests/responses examples document.

● Discuss with the publisher which method of payout confirmation you are going to use: ADM, NURL, BURL. Make sure to set the same method under the platform settings and double-check with the publisher. Note, the wrong method will lead to discrepancies on both sides. ADM method is more preferable.
● Ask the publisher to send you just those GEOs and Categories which your demand is interested.
● Negotiate with the publisher using which Auction type you are going to work with - Second Price, First Price. Preferably to work via Second Price auction.
● Discuss with the publisher which minimal TMAX they should send you. This metric really depends on which min TMAX is accepted on the side of your Demand. Note, that the higher TMAX is, the higher chance that it is coming from the direct supply, and wise verse. Also, there is a higher chance that your Demand will be able to place the bid. The optimal min TMAX is 350 ms.
● Discuss with the publisher the max BidFloor which the majority of your demand is interested in, so they send you the most relevant traffic and don’t break your average statistic.
● Let the publisher know the impressions expire time on your side (TTL), so they configure it on their side as well and don’t charge you for expired impressions.

● Ask the publisher which IP determination library they are using. This is essential for proper GEO matching on the side of your platform. The most commonly used library is MaxMind.
● Ask the publisher to send you required request parameters if your demand is interested just in such traffic. For instance IFA parameter.
● Let the publisher know all the impression filters which you have set on your side: duplicates, IP mismatch, GEO mismatch, Device mismatch, OS mismatch, etc. And ask him to apply the same settings on his side in order to decrease the chance for discrepancy between your platforms due to this reason. Monitor the number of rejected impressions and the numbers which your publisher’s API is reporting to you, if you see the discrepancy, check the most reason for rejected impressions and notify your publisher about it, and remind him about the filters on your side.
● Ask the publisher to set a low QPS limit on their side before sending high volumes in order to test the integration. Once you are sure that all is working well and there is no discrepancy between the platforms, your publisher can increase the QPS limits. It is suggested to start with 100-200 QPS with incremental raise.
● Clarify with the publisher if they have any specific blacklist for the creatives IDs.
● Apply BL of well-known bundle IDs or websites which are blacklisted.

Discrepancies waste money for everybody. A world in which discrepancies do not exist might seem like a pipe dream, but the industry needs to prioritize making it happen.
One more step to deal with discrepancy is properly configuring the Advertiser endpoint.
Follow each step before making the endpoint live.

Illustration

Step 2: configure endpoint (EP) of advertiser before making it live

● Negotiate with the advertiser by which numbers you are going to bill them and terms of payments. Advertisers most likely will ask you to work on their numbers.
● Provide the advertiser with a Statistic API URL so they can pull the stats from the platform and monitor if there is discrepancy between your and their numbers.
● Ask the advertiser to provide their Statistic API URL and insert it under the certain Feed with START_DATE, END_DATE macros to be able to monitor what they count and troubleshoot instantly.
● Ask the advertiser if they have an integration document with examples of the supported OpenRtb requests/responses for all ad types you are going to work with.
● Ask the advertiser what are the required bid request parameters for them that are not mandatory according to oRTB specification? For many DSPs in order to properly identify and retarget user the mandatory parameter would be IFA.
● Ask the advertiser where they have their data centers located.

● Ask the advertiser using which method of payout calculation you are going to work with - ADM, NURL, BURL. Preferably to work with the ADM method.
● Confirm with the advertiser which Auction Type you are going to work with, First Price or Second Price. First Price is more profitable for Ad Exchange.
● Ask the advertiser which GEO and Categories they are interested in.
● Ask the advertiser which min TMAX they will be able to process.
● Ask the advertiser which max Bid Floor they are willing to pay.
● Ask the advertiser which max QPS should be sent to their endpoint. It is suggested to start with a low QPS limit in order to check the integration and scale once you are sure that you don’t have the discrepancy on both sides.

● Ask the advertiser which impressions expiry time (TTL) their platform supports. The default TTL on Ubidex is 20 minutes.
● Ask the advertiser in which format is better to send them a GEO mark, Alpha2 (US) or Alpha3 (USA).
● Ask the advertiser if any specific filters set for impressions on their side duplicates, IP mismatch, GEO mismatch, Device mismatch, OS mismatch, etc. This needs to be clarified in order to minimize discrepancy and should be reflected on the Feed settings accordingly.
● Ask the advertiser which IVT tool they are using and if they are able to provide you with the stats of rejected traffic.
● Ask the advertiser if they have any specific BL/WL which should be applied on your side.
● Ask the advertiser if they set any budget/impressions/clicks caps on the pub endpoint and what are the rules (e.g. certain daily budget, cap per device IP, cap per bundle, etc)

This is the end of UBIDEX guide "How to deal with DISCREPANCY".
You can tackle discrepancies by following the process explained above. The properly configured endpoint is one of the main points to perform better and stop losing your money.
Get the whitepaper on Slideshare