Analytics: cookieless product analytics

Cookieless analytics measures how people use a website without storing an identifier on their device. Classic analytics tools write a cookie, which ties visits together and usually requires consent first. A large share of visitors refuses or ignores the banner, so the numbers go missing.

Cookieless tools count visits with no device storage, and that keeps a basic measurement available before any consent choice. The trade is real: you lose the ability to follow one person across several days.

Analytics takes a two state approach. Before consent it runs cookieless. Once a visitor accepts, it switches to full product analytics with a stable visitor, funnels across visits and session replay.

You can choose a stricter mode. With whenUnknown: 'off', nothing is collected before a choice. The package can also read the choice from your consent platform, so visitors see one banner.

Without storage, the collector cannot tell whether two page loads came from one person. The collector offers two options.

No IP address is stored. Your privacy policy should still describe this measurement.

Each module turns on or off by itself. Replay and surveys stay off until a project enables them.

Clicks store a label and a selector in place of the full element tree, which keeps stored data small.

Three families of tools answer different questions, and vendors often blur them.

Analytics covers the first four in one package from one event stream. Separate tools each keep their own copy of your visitors, and their numbers rarely match. Logs remain useful for bots and errors, since AI crawlers run no JavaScript.

Cookieless numbers and consented numbers are different populations. Visitors who accept tend to differ from those who refuse, so avoid mixing them in one funnel without saying so.

Google publishes three measures of real user experience, and the webVitals module collects them from your visitors.

Field data from real devices often looks worse than a test on your own laptop. Read it per page and per device.

Inconsistent events break reports: signup, Sign Up and user_registered can all mean one thing. Agree on names before anyone writes code.

A plan for a lead generation site can stay short.

Start with about ten events, and add one only when someone will read it.

The trafficSource module reads the referrer and the campaign tags of each session. UTM tags are parameters you add to a link, so a report can tell one campaign from another.

https://example.com/offer?utm_source=newsletter&utm_medium=email&utm_campaign=spring

Keep tags in lower case and write the list down, since Email and email become two sources in a report. Leave tags off internal links, because they overwrite the true source of the session.

Paid clicks carry their own click ids. Those are stored only with consent, so an offline conversion upload depends on the visitor having accepted.

A script served from an analytics vendor's domain sits on most blocklists. An endpoint on your own domain, such as /api/site-events, appears as part of your site, so fewer requests are lost. Privacy tools can still block it, and visitors keep their right to refuse. A first party endpoint improves data quality and leaves your consent duties unchanged.

Bots add noise from the other side. Many run no JavaScript and never reach the collector, while others do. Compare your analytics totals with your server logs from time to time.

The package installs as a private tarball, so the site keeps it in its own repository. Three pieces connect it.

The layout wraps the app in a provider.

import { AnalyticsProvider } from '@infra/analytics/react';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        <AnalyticsProvider endpoint="/api/site-events" projectKey="my-site">
          {children}
        </AnalyticsProvider>
      </body>
    </html>
  );
}

A route on your own domain receives the events.

import { createCollector, createMongoSink, createRouteHandler } from '@infra/analytics/server';
import { getAnalyticsDb } from '../../../lib/analytics-db';

export const runtime = 'nodejs';

export const { POST } = createRouteHandler(() =>
  createCollector({
    sink: createMongoSink({ db: getAnalyticsDb, projectKey: 'my-site' }),
    projectKey: 'my-site',
    onError: (error) => console.error('[analytics]', error),
  }),
);

Any client component can then record a business event.

const analytics = useAnalytics();
analytics.track('quote_requested', { plan: 'pro' });

The endpoint sits on your domain, so requests reach your own server. That makes the setup first party, and it means the events land in a database you already run.

Session replay records what a visitor did on the page so you can watch it back. Done carelessly, it records passwords and personal data.

Here, the recorder loads only with consent. Visitors without consent never download it. Every input, textarea and select is masked, along with any editable content, and no option turns that masking off. Setting maskAllText: true masks page text too, and data-analytics-mask masks one element.

Recordings are compressed, stored per session and kept for 30 days. The collector refuses a recording unless replay is on for the project and the event was collected with consent. The recorder weighs about 35 KB gzipped.

An A/B test shows two versions to two groups and compares the results. Assignment needs a visitor who stays the same between page loads, so it needs granted consent.

Assignment sticks once made. Changing the weights or adding a variant moves nobody already assigned. The hook works in any component.

const variant = useVariant('pricing-page');
const enabled = useFeatureFlag('new-checkout');

Flags live in code or come from your own server. There is no separate flag service to run.

Query helpers compute each report from your stored events.

const retention = await sink.queries.retention({ period: 'week' });

Take a quote form with four ordered steps. Over a month, the funnel returns these counts.

Overall conversion is 9.8%. The largest loss sits at the first step, so start with the page above the form. Field level abandon events then show where people stop inside the form.

Read a funnel per source too. A step that works for search visitors can fail for paid social visitors, who arrive with less intent. The figures above illustrate the method and come from no client.

Retention groups visitors by the week of their first visit and counts how many return.

Read down the columns, since a newer cohort that holds better means a change worked. A curve that flattens shows a group of people who keep coming back. These figures are also illustrative.

Retention needs a stable visitor, so it counts consented visitors. Cookieless days cannot be linked.

A difference of a few conversions proves little, so let a test finish.

Small sites rarely reach enough conversions for a fair test. If a page gets a few conversions a week, use interviews and session replay in its place.

1. Export or screenshot the reports you read, since history stays behind.
2. Write the tracking plan.
3. Run both tools side by side for a month.
4. Compare totals per source, and expect a gap between them.
5. Rebuild the reports your team reads each week through the query helpers.
6. Remove the old tag and update your privacy policy.

Two tools will never match exactly, because they differ on bots, consent and session rules. Look for stable trends.

A heatmap combines the clicks and scroll depth of many visitors on one page.

Read phones and desktops apart, since the layouts differ. A heatmap on a page with a few dozen visits shows noise, so wait for volume.

Rage clicks and dead clicks turn vague complaints into a list of places to look.

1. Sort the pages by frustration events per visit.
2. Open a consented replay of a session on the worst page.
3. Note what the visitor expected.
4. Fix the cause, then compare the same measure a week later.

jsErrors groups JavaScript errors, so a bug that hits one browser appears as one line with a count. Set aside time each week to read that list, because users seldom report these errors themselves.

A short question at the right moment can explain what numbers cannot. Surveys run with consent. Ask one thing, close to the event: "What almost stopped you from signing up?" on a confirmation page gives you the wording for your next headline. Keep answers free of personal data, and read them in full, since a count of themes loses the voice of the customer.

Events default to a 13 month lifetime, and replay to 30 days. With consent, the visitor id lasts 13 months from creation, and a new visit does not extend it. You store the data in your own MongoDB.

The cookieless mode was designed around the conditions the French data authority sets for audience measurement without consent: first party, for the publisher alone, statistics only, no cross site tracking and no merging with other processing. Nobody has audited or certified that design. Whether your deployment qualifies is a decision for your own counsel, and your site must still describe the measurement in its privacy policy and offer a way to refuse.

Replay, surveys and person properties fall outside that exemption and require consent.

Your banner affects how much consented data you collect. Regulators in several countries ask for refusing to be as easy as accepting.

The package reads the state you give it, so any banner works. Keep the words on your banner in line with what the code does: if replay runs after consent, the banner must say so.

Choose a hosted tool if your team wants ready dashboards today. Choose a self hosted package if owning the data matters more and you already run a database.

1. Which questions must it answer in the next quarter?
2. Who reads the reports, and how often?
3. Where does the data live, and for how long?
4. What runs before consent?
5. Can you export raw events?
6. What happens to the cost when traffic grows tenfold?
7. Who fixes it when the numbers look wrong?

Keep the list short, and read it on a fixed schedule.