> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/data-and-insights/marketing-integrations/adpage-tracking.md).

# AdPage Tracking

Your own server-side tracking data — always on, and the source everything else is checked against.

This is the one integration you do not connect. If you have server-side tagging with AdPage, it is already on, and it is the foundation the rest of your reports sit on.

Every other integration tells you what one platform thinks it did. AdPage Tracking is what actually arrived at your own server.

### What it is

Your server-side container writes every request it handles into your own tracking database. Because that happens on your server rather than in the visitor's browser, it does not lose events to ad blockers, short-lived cookies or a tab closed too early.

The tile on the Integrations page shows it as always active, with the tables it holds and how many rows are in each over the last 90 days.

### What it holds

| Table                  | What it records                                                         |
| ---------------------- | ----------------------------------------------------------------------- |
| `incoming_requests`    | Every event that reached your server container — the raw inbound stream |
| `outgoing_requests`    | What your container forwarded on, and to which platform                 |
| `webhook_events`       | Events received by webhook, such as order confirmations from your shop  |
| `webhook_request_logs` | The delivery record for those webhooks                                  |
| `ga4_requests`         | Events forwarded to Google Analytics 4                                  |
| `ga4_request_logs`     | The delivery record for those, including what GA4 answered              |

The pairing is the useful part. `incoming_requests` against `outgoing_requests` shows what arrived versus what was passed on — and the gap between them is where tracking problems live.

### What you get

* **Data Quality** — events arriving but not forwarded, conversions missing a click ID, requests a platform rejected.
* **Attribution** — the measured customer journey, built on events that actually arrived rather than on what survived in a browser.
* **The Data Assistant's evidence base.** When you ask why a channel's conversions dropped, this is what it reads.
* **A check on every other integration.** Where a platform reports far more or far fewer conversions than arrived at your server, that difference is a finding in its own right.

### Reading the numbers

**Server-side counts are usually higher than browser-based ones.** That is the point — it is not double-counting, it is events that GA4 in the browser never received.

**Row counts include everything.** Bots, monitoring and your own testing all produce requests. A sudden spike in `incoming_requests` with no change in revenue is usually a crawler, not a good day.

**Retention is not forever.** Tables hold a rolling window. A question about last year is better answered from a platform integration than from raw tracking.

**A forwarded request is not an accepted one.** `outgoing_requests` records that something was sent; the `_logs` tables record what the platform said back. A 200 with an error body is a failure that only the logs reveal.

### Troubleshooting

**The tile shows zero rows.** No events are reaching your server container. Check that your web container is forwarding to it, and that the server container is live — this is a tagging problem, not a connection one.

**One table is empty and the others are not.** That path is not configured. Empty `ga4_requests` means GA4 forwarding is not set up; empty `webhook_events` means your shop is not sending order webhooks.

**Incoming is much larger than outgoing.** Events are arriving and not being forwarded — usually a tag without a trigger, or consent blocking it. Connect [Google Tag Manager](/data-and-insights/marketing-integrations/google-tag-manager.md) so the audit can name the cause.

**Row counts look stale.** The tile caches counts for a few minutes. Reload after a short wait.

Still stuck? Contact <support@adpage.io> with the container and what you expected to see.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.adpage.io/data-and-insights/marketing-integrations/adpage-tracking.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.