A short-link visit and a GA4 session measure different things. A request can reach the redirect service without producing a measured session on the destination website. Repeated opens can also belong to one existing session. Check the definition, destination and reporting window before calling the difference lost traffic.
This guide applies when a QR contains a short URL leading to a website you can inspect. It is a troubleshooting workflow based on Google's documentation and a review of 302.sh's reporting implementation. We did not run a controlled GA4 experiment for this article. The diagram is explanatory, and the test record below is blank for your own observations.
Name the measurement before comparing it
| Measurement | What it can establish | What it cannot establish alone |
|---|---|---|
| QR decoded | A reader recognized the encoded address. | The person opened it or reached your website. |
| Short-link visit | The service recorded a request under its collection and filtering rules. | A physical scan, distinct person or completed page load. |
| GA4 page event | Analytics received a reported page interaction. | A new session or business outcome. |
| GA4 session | Activity was grouped under GA4's session rules. | Exactly one QR open. |
| Business outcome | The separately verified action, such as an accepted booking. | That every earlier request was a potential customer. |
Google defines a session as a period of interaction. A page view starts one when no session is active; the default inactivity timeout is 30 minutes and can be changed. Opening the same short URL again during an active session therefore need not add another session. GA4 also estimates session totals from distinct session IDs. See Google's session definition and counting method.
A QR image and a typed, bookmarked or forwarded copy of its URL can reach the same entrance. Unless your distribution scheme separates those uses, the short-link report cannot distinguish them. Our QR tracing guide covers identifying the encoded address; this article starts with the reports after that step.
Make the two reports comparable
Write down the exact short hostname and path, final destination, GA4 property and web stream. Then record each report's metric, time zone, start and end timestamps, filters, and the time you retrieved it. “Yesterday” in one time zone can cover different hours from “yesterday” in another.
Compare the relevant destination and campaign, rather than all website sessions against one QR link. Check whether the GA4 report uses session-scoped acquisition dimensions or a different scope. Do not replace visits with unique visitors simply because the latter happens to be closer to GA4 sessions.
On 302.sh, entry collection runs separately from the destination's analytics tag. The current implementation can stop recording after the analytics allowance is consumed while continuing redirects. Reporting can exclude requests flagged as bots; that classification is not proof that every remaining request came from a person. Totals use sampling weights, and visitor estimates use IP-based signals with a compatibility fallback for older records. Those estimates are not GA4 sessions. See the link analytics overview and check the report's own filters and coverage notices.
Start with the symptom you can observe
These are possible explanations to investigate, not diagnoses inferred from a ratio.
| Symptom | Evidence to inspect | Possible explanation | Next check |
|---|---|---|---|
| More entry visits than sessions | Labelled repeat opens, page events and active-session state. | Several requests belong to one session. | Separate a first arrival from repeat opens in your test record. |
| Entry visits, but no destination events | Final URL, page load, tag status and consent state. | Navigation stopped, the wrong page loaded, or collection did not run. | Follow one browser journey and inspect each stage. |
| Page events appear, but the campaign is missing | Final query string, measured page URL and acquisition dimension. | Parameters were changed, or the report uses a different attribution scope. | Check the full redirect chain and the chosen dimension. |
| A spike after sharing a link privately | Request timing, bot classification and sharing context. | A preview or automated check may have requested the address. | Look for corroborating evidence before calling the spike human traffic. |
| Sessions exceed entry visits | Landing pages, other traffic sources and entry-report coverage. | People arrived another way, or entry collection omitted events. | Narrow the comparison and check quota, retention and reset boundaries. |
| Today's reports disagree with later exports | Retrieval time, report type, time zone and filters. | Processing or different reporting windows changed the comparison. | Repeat the same saved query after processing. |
Google says GA4 processing can take 24–48 hours and reports may change during that period. Realtime and daily reporting have different coverage and freshness. Use immediate tools to debug collection, then review processed reports for the same window. These are typical processing expectations, not a deadline by which two systems must match. See GA4 data freshness.
Check consent behavior without guessing
Do not assume every declined banner causes the same analytics behavior. In Google's basic consent mode, tags are blocked until consent is granted. Advanced consent mode can send measurements without cookies while consent is denied; modeling also depends on eligibility. Record which implementation you actually use and what Tag Assistant shows. Google's consent mode overview explains the distinction.
Browser extensions, network rules and tag configuration are other things to inspect. A missing event by itself does not identify which one intervened. Keep visitors' consent choices intact while troubleshooting; your test should reveal the configuration you operate.
Run a small, labelled check on your own site
- Choose a controlled destination. Use a page and GA4 property you own or are authorized to test. Confirm the expected measurement ID. Use a dedicated test link and campaign label so your activity can be separated from customer traffic.
- Save the configuration. Record the encoded short URL, expected destination, campaign parameters, consent setup, browser, time zone, active filters and session timeout. Do not put personal information in campaign values.
- Follow the original QR. Decode it, open the address once and record the start time. Verify the visible page and the complete final URL. If there are several redirects, inspect where the address or parameters change.
- Check collection on that device. Connect Tag Assistant or enable debug mode for your own device. Look for the expected page event and, where applicable, session start. Record consent state and whether the measurement request was sent; do not infer success solely from the page rendering.
- Repeat deliberately. Open the same entrance again in the same browser during the active session. Label this separately. If you test a later visit, wait beyond the configured inactivity timeout without interaction and record the actual timing.
- Reconcile each stage. Check entry reporting, debug events and later processed sessions independently. Record unavailable evidence as unavailable. Investigate the first stage that differs from what you observed, rather than adjusting totals until they agree.
Google's DebugView instructions explain how to enable device debugging. They also note that privacy controls or denied analytics-cookie consent can prevent events from appearing there. An empty DebugView is a reason to inspect those conditions, not proof that the short link failed.
For a visual walkthrough, watch Troubleshooting in Google Analytics on the official Google Analytics YouTube channel. It covers Realtime at 0:39, Tag Assistant at 2:54 and DebugView at 7:41. Published in 2023, it is useful for the workflow; use the current documentation for interface details.
Copy this blank test record
Fill this in during your test. These rows are a template, not measured results. Keep raw timestamps and configuration notes with any screenshots you retain.
| Test condition | Time + final URL | Entry evidence | GA4 evidence + retrieval time |
|---|---|---|---|
| First labelled open | To record | To record | To record |
| Repeat during active session | To record | To record | To record |
| Later open after inactivity timeout | To record | To record | To record |
If campaign parameters are the first discrepancy, use our UTM URL builder guide to review naming and placement. Then verify the actual destination URL again. A correctly formatted UTM string does not install a tag or guarantee session attribution.
When the destination belongs to someone else
A QR leading to Google reviews, WhatsApp or another third-party service does not give you access to that service's GA4 property. Adding UTM parameters cannot grant that access. You may be able to measure the entrance or use reports provided by the destination, but those are separate sources with their own definitions.
If you need a booking or purchase count, identify an authorized source for that completed action before designing the campaign. Entry visits can help compare access patterns; they cannot establish completed reviews, messages or sales. Use the 302.sh analytics demo to understand the entry report, then pair it with the destination evidence you can actually obtain.
What is included in 302.sh?
Free allows 5 new links per UTC month and up to 50 owned links, with 5 custom slugs per month of at least 6 characters. Deleting a link does not refund its monthly creation allowance.
Free includes 2,000 analytics events per month and 90-day retention. Reaching that analytics allowance stops additional tracking, not redirects. Link deletion, owner-set limits and safety enforcement can still stop redirects. Branded domains require a paid plan and completed domain setup. See current plans and limits.
Try the workflow
Explore the dashboard demo, or create a short link using a destination you own or are authorized to share. Verify the destination before distributing it.