Documentation

Three reasons, all structural. Roughly 1 in 3 visitors run an ad blocker that stops the GA script but not a script served from your own domain. In the EU, a large share of visitors decline analytics cookies — GA either drops or statistically models those visits, while a consent-aware first-party setup keeps counting what it's allowed to. And GA4 applies sampling to complex reports above 10 million events; Lynq never samples.

A 10–20% gap is normal and expected. If unique visitors differ wildly beyond that, something is misconfigured — that's worth a debugging session, and we do those.

No, at any traffic level. Every report is computed from every event. The backend is ClickHouse, a columnar database built for exactly this — billions of rows aggregate in milliseconds without shortcuts. GA4, by comparison, samples explorations past 10 million events, and the margin of error on sampled reports can reach 30% for narrow date ranges.

Mostly, and honestly: mostly. Blocklists like EasyPrivacy target known tracker domains — googletagmanager.com, connect.facebook.net, and so on. A script named neutrally and served from data.your-domain.com isn't on those lists, so standard ad blockers let it through. The most aggressive setups (blocking all third-party requests won't catch it, but blocking all JavaScript will) can still stop it. In practice the difference against GA is large; a claim of literally 100% would be dishonest.

Yes. Known bots, crawlers and monitoring services are filtered server-side by user agent and behavioral patterns before events reach your reports. This is another reason your numbers won't match GA4 exactly — GA4 lets some spam and bot traffic through that we drop.

Analytics revenue and financial revenue answer different questions. Lynq records a purchase when the browser fires the event — usually the thank-you page. Your backend records it when payment settles. Refunds, cancelled orders, failed captures and customers who close the tab before the thank-you page all create small gaps.

Treat your backend as financial truth and Lynq as marketing truth: which channel, which campaign, which page produced the order. The gap should be small and stable — if it suddenly grows, an event broke, and that's exactly the kind of thing we catch in the verify step.

The honest answer: it depends on where your visitors are, and anyone who gives you a flat "no" is oversimplifying. "First-party" is not a consent exemption by itself — the ePrivacy rules cover any non-essential storage on the visitor's device, whoever sets it.

What it looks like in practice: several EU countries (France, Italy, Spain, the Netherlands) exempt tightly-scoped, aggregate-only audience measurement. The UK added a statistical-purposes exception in February 2026 that works on an opt-out basis. The US works on notice and opt-out, not opt-in. In stricter EU markets, analytics cookies still need consent.

This is why consent design is part of onboarding, not an afterthought: we wire the tracker to your banner, agree with your legal team on what fires before and after consent per market, and document the decision so you can defend it.

Lynq collects no names, emails, or precise locations, and IP addresses are hashed with a daily-rotating salt before anything touches disk. Most customers process this under legitimate interest (GDPR Art. 6(1)(f)) for aggregate measurement, with the cookie question handled separately per market — see the consent answer above. We provide the data inventory (see Collected Data) your DPO needs for the assessment.

Yes. You are the controller, Lynq Studio is the processor, and we sign a standard DPA that covers processing scope, sub-processors, retention and deletion. Since analytics data lives on EU infrastructure and never leaves it, there are no third-country transfer acrobatics to explain to your DPO.

There is usually nothing to hand over, and that's by design. Visitors are anonymous: no name, no email, no raw IP is ever stored, and the visitor ID is a random first-party cookie value that can't be tied back to a person by us or by you. If a visitor sends you their cookie ID, we can locate and delete those rows — but there is no profile behind it.

US state laws (California and the growing list of others) work on notice and opt-out rather than opt-in. Lynq doesn't sell or share visitor data with anyone — there's no third party in the chain — which keeps you out of the "sale/share" machinery entirely. Honoring GPC signals can be wired into the setup if your policy requires it.

Default is 2 years for analytics events, configurable per workspace if your policy requires shorter. Account data lives as long as your contract. On termination, your data is exported to you on request and then deleted — it isn't retained as leverage.

Email privacy@lynq.studio. Everything is deleted within 30 days, confirmed in writing.

Three usual suspects: the snippet isn't in <head> on the page you're testing; the data-website-id doesn't match your project; or a Content-Security-Policy blocks your tracking subdomain. Realtime shows events within seconds when everything is wired correctly — and we're one message away during setup.

No. It's ~2 KB (gtag.js is around 50 KB), loads with defer so it never blocks rendering, and is served from your own domain — often over an already-open connection. Core Web Vitals impact is effectively zero.

Add your tracking subdomain to script-src (for the script) and connect-src (for the collect endpoint). Because it's your own subdomain, you aren't whitelisting anyone else's infrastructure in your CSP — a detail security teams tend to appreciate.

Yes. The tracker detects client-side navigation (pushState / replaceState) and records page views accordingly. Next.js, Nuxt, SvelteKit, plain React routers — no extra code needed.

Yes. The first-party cookie is set on the root domain, so a visitor moving from www to shop to app stays one visitor with one journey. Whether that's one project or several in the dashboard is a schema-design decision we make together.

Yes, indefinitely — the scripts don't interfere. The standard migration pattern: run both for 2–4 weeks, compare unique visitors (not page views — counting methods differ), and once you trust the numbers, drop the GA tag. Many customers keep GA4 during a transition quarter for continuity.

Lynq starts counting from install day; there's no automated GA4 importer today. What we do instead during onboarding: help you export the GA4 reports that matter before Google's retention window deletes them (event-level data is kept only 2 months by default, 14 on paid settings), and archive them next to your Lynq data so year-over-year comparisons stay possible.

Yes. Each website or app gets its own project ID, and you switch between them in the dashboard header. Web, iOS, Android, and Flutter are all supported and share one event schema.

Storefront and product pages work with the standard snippet. Shopify's checkout is sandboxed, so purchase events need Shopify's own hooks — we set that up during onboarding so orders land with full attribution. The same applies to other hosted checkouts (iyzico, Stripe Checkout): the pattern is a thank-you page event or a server-side call from your order webhook.

They don't, automatically — the browser fired purchase when the order was placed, and analytics keeps that as marketing truth. If refund-adjusted reporting matters to you, the collect API accepts server-side events from your order system, and we design that into the schema.

Send the ISO currency code with every purchase event — reports use the values you send. Most multi-currency stores pick one reporting currency and convert at event time on their side, which keeps the dashboard consistent with how finance already reports.

Two views, side by side. Sources uses last external touch: the last paid or organic channel before the purchase, with direct visits never overwriting campaign data. Assisted Conversions shows the multi-touch picture — which channels appeared anywhere in the path. Google Ads introduced, Instagram reminded, direct closed: you see all three, not just the last one.

Fire form_submit with a form name on successful submit — never with the form's contents. If your form redirects to a thank-you page, that page view works as a conversion signal too. The Sources report then shows which channels produce leads, not just visits.

Yes — this is the case first-party attribution exists for. The campaign touch is stored in a first-party cookie for 90 days, and direct returns don't overwrite it. A visitor who clicked a LinkedIn ad in March and filled the form in April is credited to that LinkedIn campaign, where a third-party tool would have long lost the thread to "direct".

Yes, via the collect API. The common pattern: when a lead submits, store their Lynq visitor ID in the CRM record. When the deal closes, your CRM posts a server-side deal_won event with the value. Pipeline revenue then appears attributed to the campaign that started it — offline outcome, online source.

ATT governs tracking across other companies' apps and websites — the IDFA. Lynq's SDKs never touch the IDFA, don't fingerprint, and only record behavior inside your own app, so first-party analytics of this kind generally doesn't trigger the ATT prompt requirement. Declare your data collection honestly in the App Store privacy labels; we provide the exact field list for that.

Web and app events share one schema and one dashboard, so reports compare cleanly. By default a web visitor and an app user are separate anonymous IDs — anonymity cuts both ways. Where your product has its own account system, connecting the two is a schema-design conversation during onboarding.

No. The mobile SDKs queue events locally when there's no connection and deliver them in batches when the device comes back online, with original timestamps preserved.

Yes, with discipline. Track feature usage as events (report_exported, integration_connected) without putting names or emails in the params. You get adoption funnels, retention curves and cohort analysis while the dataset itself stays anonymous — which is also what keeps your own privacy policy short.