# No data is arriving The tag is installed and the reports are empty. This page gives you the order to check in — from the fastest signal to the quietest cause — and for each one, the symptom that identifies it and where it gets fixed. ## Start with the fastest signal Before any other check, generate an event yourself and see whether it lands. 1. Open your site with a hard reload — `Ctrl` + `Shift` + `R` on Windows and Linux, `Cmd` + `Shift` + `R` on macOS. 2. In the console, open **Realtime overview** from the sidebar. 3. Watch the **Active users** card for a few seconds; the page refreshes itself. If you can see yourself there, collection is healthy and your problem is elsewhere — jump to the last section of this page, "Realtime has data but the reports are empty". If nothing shows up, work down the list below. The order is not arbitrary: each item is more likely than the one after it, and quicker to rule out. ## The order to check in | # | Check | The symptom that identifies it | | --- | --- | --- | | 1 | Is the tag on the published page? | The measurement ID is not in the live page's source | | 2 | Is the measurement ID correct? | DevTools shows a `/collect` request answered 200, yet nothing appears anywhere | | 3 | Does the stream domain match where the tag runs? | Realtime has data but **Test installation** still says it is waiting | | 4 | Is consent blocking collection? | No `/collect` request at all, and no `__sov_*` cookie was created | | 5 | Is your IP excluded? | Your colleague is visible, you are not | | 6 | Is the opt-out cookie set? | Only your browser, and not in a private window | | 7 | An ad blocker? | You appear in a browser with no extensions, not in yours | | 8 | Did you test with a command-line tool? | Only `curl` and headless-browser requests go missing | ## 1. The tag on the published page View the source of the **live page**, not your development environment and not the template file. Open "view page source" in the browser and search for the measurement ID — the value starting with `AP-`. Three things that actually happen: - **A template that got missed.** The tag is on the home page and not on the checkout page. The result is complete data for one part of the site and zero for the part that matters most. Open every independent template separately. - **A server-side or CDN cache.** You added the tag and the copy visitors receive is still the old one. Purge the cache and view the source again. - **The tag near the bottom of the page.** This does not stop data, but it loses short visits. The correct place is as high in `` as possible. If the tag appears **twice**, this is not your page — read [Page views are counted twice](analytics/troubleshooting/page-views-counted-twice). > **Never hand-build the snippet** > > The console generates the install snippet and stamps the tag version onto it. Take it from **Admin → Data streams → your stream → View tag instructions** and paste it verbatim. A snippet copied out of an article or off another site almost always has one small difference. ## 2. The measurement ID This is the quietest failure in the whole product. When a measurement ID matches no stream, AdPix **does not accept the event and does not report an error either**: the response is still a 200 and the event is filed in a quarantine table. Everything looks green in the browser's developer tools and nothing appears in the reports. So compare it by eye. Check the ID in the page source character by character against the **Measurement ID** shown for that stream in the console. Three common mistakes: - a staging property's ID left on the production site; - a stream that was deleted while its ID is still on the page; - an ID copied out of an email that brought a stray character — a space or a line break — with it. ## 3. The stream domain Every stream has a registered domain. Events do not carry a stream ID, so AdPix recognises each stream's traffic by its **domain**. That produces a confusing state: if the tag runs on a domain that is neither the stream's registered domain nor a subdomain of it, you **do see visits in Realtime** while **Test installation** and the 48-hour indicator next to the stream both keep saying no data has arrived. There are two fixes: correct the stream's domain, or add the second domain under **Configure your domains** on that stream. The full path is in [Cross-domain and subdomain measurement](analytics/collect/cross-domain-and-subdomain). ## 4. Consent If you have the consent module switched on, the tracker gates **itself at the source**. The category that opens collection is statistics: | Category | Until it is accepted | | --- | --- | | Statistics | No page views, custom events, e-commerce events or identify calls are sent, and the visitor ID is **never persisted** to a cookie or to local storage | | Marketing | The `__sov_ft` and `__sov_lt` attribution cookies are not written and the fingerprint-enrichment module is not loaded | In opt-in mode — the EU/EEA setting — the default is **closed**: nothing is sent until the visitor makes a choice. In opt-out mode collection runs until they decline. The symptom is unmistakable in developer tools: no request to `/collect` at all, and no `__sov_*` cookie created. To confirm it, accept everything on the banner and reload the page; if data arrives then, that was the cause. If the banner never renders while the module is on, you have the worst possible combination: the gate stays closed and the visitor has no way to open it. Check the configuration in [Consent enforcement in the tracker](analytics/privacy/consent-categories-and-gating). ## 5. An excluded IP Under **Admin → Property details** there is a section called **Traffic filtering** holding the **Excluded CIDRs** list. The screen's own hint reads: "One CIDR per line, e.g. 203.0.113.0/24. Matching requests are dropped before reporting." Three things worth knowing before they cost you an hour: - **This is a drop, not a report filter.** A matching request is discarded before anything is stored, so it never shows up in Realtime and cannot be recovered later. - **A change is not instant.** Each property's config is held in the collector's memory and refreshed about once a minute. Wait a minute after editing. - **Your egress IP is not what you think.** On a VPN or an office network, look up your public IP and compare it against the list. One optimistic `/16` can exclude half a carrier. ## 6. The opt-out cookie `__sov_x` is the opt-out cookie. If its value is exactly `1`, the tracker sends nothing and the collector discards any event that arrives with it — still answering 200. AdPix does not create this cookie; you do, usually behind a "do not track me" control. If you once set it on your own browser for a test, it is still there. Look for it in the domain's cookie list in developer tools and delete it. The giveaway is that the problem is confined to one browser and disappears in a private window. ## 7. An ad blocker In direct mode the tracker file and the `/collect` endpoint sit on an AdPix domain, and blocklists know them. How much you lose depends on your audience, and it is noticeably larger for a technical audience. The test takes a minute: open the same page in a browser with no extensions at all. If you appear there, that is the cause. The real fix is Tag Gateway: the tag and the beacon are served from your own subdomain and there is nothing left to match on. How it works is in [First-party Tag Gateway](analytics/collect/tag-gateway). > **Tag Gateway has its own configuration to get wrong** > > Turning Tag Gateway on adds a new reason for data to stop: the proxy itself. If the CNAME record or the proxy token is wrong, requests come back with a 403. **Test installation** reports that state separately — if the proxy-health signal is red, that is your root cause. ## 8. Testing with a command-line tool If you sent an event with `curl` or a headless browser to be sure, and there is no trace of it, that is deliberate. The collector inspects the user agent and routes known crawlers and command-line tools — including `curl/`, `wget`, `python-requests` and any user agent containing "headless" — into quarantine, still answering 200. Test with a real browser. ## Realtime has data but the reports are empty This is a completely different problem and has nothing to do with the install. - **The date range.** Every report defaults to the last 30 days, and the realtime pages ignore the date picker entirely. If you installed the tag today, switch the range to Today. - **The property timezone.** Days are cut in the property's timezone, not your browser's clock. Near midnight that difference moves a whole day. - **The wrong property.** Check the picker at the top of the page. If you have several properties, opening the wrong one is not a rare mistake. - **Restricted access.** If your role carries a data restriction, some rows are hidden from you. Check with the account owner. If data is arriving but the numbers disagree with another tool, go to [The numbers don't match GA4](analytics/troubleshooting/numbers-dont-match-ga4). ## Frequently asked questions ### What is the fastest way to know whether the tag works? Open your own site with a hard reload and go straight to Realtime overview. Its window is a rolling one and the date picker has no effect on it, so a real event shows up within seconds. If you can see yourself there, collection is healthy and the problem is somewhere else. ### I set the wrong measurement ID. Will I see an error? No, and that is what makes it dangerous. An event with an unknown ID is accepted, answered with a 200 and filed in a quarantine table — no browser error, nothing in the reports. Always compare the ID on the page against the one shown under Data streams. ### Why can't I see my own visit in Realtime when a colleague can? Two common causes. Your office IP is in the property's Excluded CIDRs, or the `__sov_x` cookie with the value `1` is set in your browser. Either one drops the request before anything is stored, so it never appears in Realtime either. ### We run a consent banner. How much data do we lose? In opt-in mode nothing is sent and no identifier is persisted until the visitor accepts the statistics category — the default is closed, not open. In opt-out mode collection runs until they decline. The exact share depends on your acceptance rate and is visible in the consent log. ## Related - [Verify data is arriving](https://docs.adpix.io/en/analytics/start/verify-data-is-arriving/) - [Data streams](https://docs.adpix.io/en/analytics/collect/data-streams/) - [First-party Tag Gateway](https://docs.adpix.io/en/analytics/collect/tag-gateway/) - [How consent is enforced in the tracker](https://docs.adpix.io/en/analytics/privacy/consent-categories-and-gating/) --- [Docs](https://docs.adpix.io/en/analytics/troubleshooting/no-data-arriving/) · AdPix