> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiderx.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Integration Verification and Troubleshooting

> Confirm that your integration is reported correctly and locate where a problem occurs.

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.

| Metric | Expected increase |
| - | - |
| Impressions | With **On Ad Response**, the number of requests that returned an ad; with **On Impression Event**, the number of impression tracking URL calls |
| Clicks | The number of click events sent |
| Conversions | The number of conversion events sent (if you integrate conversions) |

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

> [accordion] The ad request returns HTTP 204
>
> 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](https://docs.aiderx.io/development/en/serving-ad.md#no-ad-checklist).

> [accordion] The ad request returns 4xx or 5xx
>
> `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.

> [accordion] curl succeeds, but the request fails in the browser
>
> 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.

> [accordion] I get a response, but the ad does not render
>
> 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](https://docs.aiderx.io/development/en/serving-ad.md).
>
> 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.

> [accordion] Clicking the ad opens the landing page, but clicks do not increase
>
> 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](https://docs.aiderx.io/development/en/ad-events-and-logs.md) for event timing and examples.

> [accordion] The event request succeeded, but reporting does not reflect it
>
> 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.

> [accordion] Impressions are not counted
>
> 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.

> [accordion] Service records and A2 reporting differ
>
> 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.

> [accordion] What happens if I send the same event more than once?
>
> 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.

> [accordion] Can I check whether an individual event was collected?
>
> 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

| Check | Completion criterion |
| - | - |
| Address and permissions | The production A2 address is used, and tokens for authenticated APIs are stored only on a server |
| Identifiers | The production ad unit ID is used as `tagid`, with no verification ID left in the configuration |
| No ad | HTTP `204` and passback responses hide the ad area or show default content |
| Request failure | Timeouts and `4xx` or `5xx` responses preserve the existing screen |
| Creative rendering | Loading failure and click behavior are verified for every creative type in use |
| Ad tracking identifier | `ad` and `ext.ad_log` from the ad response are stored and passed together |
| Event delivery | Impressions follow the selected tracking mode, and one click or conversion is never sent repeatedly |
| Reporting | On a verification ad unit, impressions, clicks, and (if you integrate conversions) conversions increase by the number of actions run |

## 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.

| Category | Information to include |
| - | - |
| Environment | A2 hostname, test or production environment, and A2 version |
| Time | Date, time, time zone, and frequency |
| Reproduction | Steps, expected result, and actual result |
| Request | HTTP method and path, plus headers and body with sensitive data removed |
| Response | HTTP status, response body, and `x-request-id` when present |
| Ad and tracking identifiers | `tagid`, `ad.id` and `ext.ad_log` from the response, and the affected event type |
| Runtime | Server, web, or app; browser or app version; and related console or network errors |

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.