Skip to main content
This page covers how to confirm that your integration is reported correctly and how to find the cause when something goes wrong.

​
Verify results through reporting

There is no way to look up individual events, so you judge whether your integration works from reported totals. Other traffic makes the results impossible to separate, so run a fixed number of actions on a verification ad unit.
1

Record the baseline

In Analytics > Inventory Analytics > AdUnit Analytics, record the verification ad unit’s current impression and click counts, and check the allocation’s Impression Tracking Mode.
2

Run a fixed number of actions

Render and click the ad in your service. Record how many ad requests, impression tracking URL calls, and click events occur, and don’t resend an event you already sent to check it.
3

Check reporting

After about a minute, reload the AdUnit Analytics page in your browser and compare the counts with your baseline.
HTTP 200 from the event API means the request was received, not that reporting is complete. With the default settings, events are usually reflected within a minute, and AdUnit Analytics splits dates in Korea Standard Time. If the counts still haven’t changed after reloading the page, check the common issues below; if you can’t find the cause, prepare the information for a support request and contact A2.

​
Common issues

This is a valid no-ad response. It confirms access and no-ad handling, but rendering and clicks are not verified yet. To verify with an ad that can serve, check the following:
  • The tagid in the request path matches the ad unit ID.
  • An ad that can be served is allocated to the ad unit.
  • Any targeting or ad_size in the request matches the configuration.
For serving conditions, see Settings to check when no ad is served.
400, 415, and 422 mean the request is malformed. Check the Content-Type: application/json header and the JSON body.In the current version, an invalid ad unit ID or an ad unit that cannot be found also returns 500, so check the tagid first. If the same request keeps returning 5xx, record the time of the request and the x-request-id header if the response includes it.
Check the Console and Network tabs in browser developer tools for these errors:
  • CORS error: a proxy or deployment setting restricts the page’s origin (A2 allows all origins by default)
  • Preflight (OPTIONS) failure: a proxy or firewall blocks the preflight request
  • Mixed content: an HTTPS page calls an HTTP A2 address
When you contact your deployment team, include the page address, the request URL, and the Console error message.
First confirm that the HTTP 200 response contains ad. If there is no ad but ext.passback is present, the fallback ad tag configured for the ad unit was returned. See no-ad handling in Ad Serving Integration.If ad is present, check that you use the field for the creative type:
  • Image banner: ad.display.banner
  • Native: ad.display.native
  • HTML markup: ad.display.adm
If the field is correct, use browser developer tools to check for failed image or HTML requests and Console errors.
Landing-page navigation and click-event delivery work separately. Check that you sent the clicked ad response’s ext.ad_log unchanged with action set to clk. An ad_log from another ad response, or a modified value, will not connect the event to the ad.If navigation cancels the request on the web, use the Fetch API keepalive option or send the event from a server. See Ad Event and Log Integration for event timing and examples.
HTTP 200 from the event API means the request was received, not that reporting is complete. Check that the request time, action, and ad_log are correct. Then, after about a minute, reload the AdUnit Analytics page in your browser and select the same ad unit and date.
Check the allocation’s Impression Tracking Mode.
  • On Ad Response: A2 records the impression when it returns the ad response.
  • On Impression Event: The impression is recorded only when the client calls the impression tracking URL from the response.
Make sure both results use the same ad unit, period, and event condition. Even if your service records a click, A2 does not count it when the A2 event request is canceled or fails.To investigate, select a time window from your service records and compare the event time, event type, tagid, and ad_log with A2 metrics. Reproducing one event at a time with a test ad unit makes the cause easier to find.
A2 doesn’t automatically remove duplicate deliveries of the same event. Duplicate requests that are processed normally can each be counted, so implement your integration so that one event isn’t sent repeatedly. The same applies to calling the same impression tracking URL more than once.If a user actually clicks an ad several times, send an event for each click. Just make sure retries or duplicated code don’t send the same click twice.
There is no screen or API for checking the collection status of an individual event. Check whether the metrics increase in AdUnit Analytics. If they still do not increase after you check the items above, prepare the following information and contact A2.

​
Before production

​
Information for a support request

Collect the following information immediately after reproducing the issue. It helps locate the failure between the request and reporting stages. Remove access tokens, passwords, cookies, user identifiers, and personal data. A2 support may need ad_log to connect the affected ad response and event. Do not post it in a public channel; provide it through an agreed private channel when requested.