Cookieless conversion tracking: how to track forms, signups and sales

Yes. Cookieless conversion tracking records meaningful actions on your website without using cookies. You can count successful form submissions, signups and purchases, and analyse the context available for those events. The main limitation is attribution: measuring an action is not the same as identifying the same person across devices or over several weeks.

This guide explains how to set up conversion tracking with MetriXs, what to measure, and where the boundaries are.

Cookieless conversion tracking records a website action as an event without relying on cookies to identify the visitor.

When someone successfully submits a contact form, your website can send an event such as Lead Submitted. The analytics system records the event, along with appropriate context such as the page and non-personal properties you choose to include.

That lets you answer questions such as:

• How many demo requests did our website generate?
• Which subscription plans do new customers choose?
• Where do visitors leave the checkout?
• Which recorded traffic sources contribute revenue?

You do not need a persistent advertising profile to count a completed signup.

However, “cookieless” describes a technical characteristic, not a blanket privacy or legal guarantee. A system can avoid cookies and still process personal data or use other tracking technologies. What it collects, how it identifies visitors and what it does with the information all matter.

Before adding code, define the outcome you actually want to measure.

A button click is not necessarily a lead. A visit to a registration page is not a completed signup. Entering checkout is not a sale.

A download click measures intent to download; it does not prove that the visitor received or read the file. Similarly, a completed order and a settled payment are not always the same thing. Choose definitions that match your business.

Start with one primary conversion. For a service business, that might be a qualified enquiry. For a SaaS product, a completed signup. For an online store, a confirmed order.

You can add supporting events later.

Add your website to MetriXs and copy the installation snippet supplied for your site. Follow the tracker installation guide or use the appropriate platform integration.

Install the tracker only once. If a plugin already adds it, do not also insert the same script manually.

Once the tracker has loaded, your website can record custom events through the global window.metrixs() function.

The examples below belong inside your existing application’s success handlers. They are event calls, not complete form or checkout implementations, and assume that the tracker is available.

For a contact form, send an event after the server confirms that the submission succeeded:

window.metrixs('Lead Submitted', {
  props: {
    form: 'contact',
    location: 'contact_page'
  }
})

The properties describe the form, not the person submitting it.

Avoid firing this event as soon as someone presses the submit button. A click can be followed by a validation error, a failed network request or a rejected submission.

The correct sequence is:

1. The visitor submits the form.
2. Your application validates and sends the request.
3. Your backend confirms success.
4. Your application records Lead Submitted.

If you use a form plugin, connect the event to its documented successful submission callback rather than a generic click or submit listener.

Keep form contents out of analytics

Do not attach names, email addresses, phone numbers or message contents to the event.

For example, form: 'contact' is useful context. The visitor’s email address is not needed to count an enquiry.

Also review the recorded page URL. Personal data can accidentally enter analytics through query strings, confirmation links or URLs containing account identifiers. MetriXs supports a URL override for custom events, but your pageviews and other automatically captured events need the same attention.

Your CRM should hold the enquiry. Your analytics should measure that an enquiry happened.

Apply the same principle to account registration:

window.metrixs('Signup Completed', {
  props: {
    plan: 'free',
    signup_location: 'pricing_page'
  }
})

Fire the event after successful account creation, not when the registration form opens.

Keep property values consistent. If you use free, basic and pro as plan names, use those exact values everywhere. Mixing Pro, pro-plan and premium makes the breakdown harder to interpret.

In MetriXs, user-defined events appear in the Custom Events card. Expand an event to see its property breakdowns. This lets you compare, for example, recorded signups by plan.

See the custom events documentation for the available options.

A confirmation screen can appear more than once. Users refresh pages, applications retry requests, and payment providers may deliver the same webhook repeatedly.

Your implementation should emit the conversion once per successful business action. Do not assume that repeatedly loading a thank-you page represents a new conversion.

For backend integrations, use your existing business records and idempotency handling to prevent repeated processing. If both browser and backend integrations report the same action, define how duplicates will be avoided before enabling both.

MetriXs commerce tracking uses three defined event names:

Enable Commerce for your site under Settings → Sites.

Then send each event at the corresponding point in your checkout. For example, when a customer enters checkout with a €79 cart:

window.metrixs('checkout_started', {
  props: {
    total: 79,
    currency: 'EUR'
  }
})

When payment details are submitted:

window.metrixs('payment_submitted', {
  props: {}
})

When the order is confirmed:

window.metrixs('order_completed', {
  props: {
    total: 79,
    currency: 'EUR'
  }
})

The amount above is illustrative. In production, use the actual confirmed order total and its currency.

These events power the commerce dashboard’s revenue, average order value and checkout funnel. You can also include the documented product properties to populate product-level reporting.

With payment flows such as hosted checkouts, a successful customer may never return to your thank-you page.

MetriXs supports sending commerce events from your backend. For payment-dependent conversions, a verified payment-provider webhook can be a more dependable trigger than a browser redirect.

Keep API credentials on the server, authenticate webhook requests and handle duplicate deliveries.

There is an important distinction here: reliably recording an order does not automatically preserve the original visitor’s attribution. A backend request does not inherently contain the browser’s traffic-source context. Confirm what your integration passes and supports before expecting source-level reporting to match browser-recorded conversions.

See the commerce integration guide for the server-side API and event format.

Shopify checkout tracking operates separately from the storefront theme.

The MetriXs Shopify integration uses a web pixel for checkout events. As documented for this integration, checkout events in EU and UK markets are subject to Shopify’s consent framework. Those recorded checkout events can therefore represent only consenting visitors.

A cookieless implementation does not bypass platform consent requirements. See the Shopify setup guide for the distinction between storefront and checkout tracking.

Once events are arriving, look beyond the total.

Suppose a store records the following during one reporting period:

These are example figures, not MetriXs customer results.

Average order value is:

€1,975 ÷ 25 orders = €79

MetriXs’ documented commerce conversion rate calculation is:

Completed-order events ÷ unique visitors × 100

For this example:

25 ÷ 1,000 × 100 = 2.5%

That is an orders-per-visitor metric. It does not necessarily mean that 2.5% of distinct people purchased: one visitor may place multiple orders, and visitor identification has its own measurement boundaries.

For custom events, make the same distinction. Thirty form-submission events do not automatically mean thirty unique leads.

The checkout figures also suggest a useful question: why are fewer payment-submission events recorded than checkout-start events? Investigate shipping costs, payment options, form errors and the event implementation itself before assuming a UX problem.

Cookieless analytics can report traffic-source and campaign context where that information is available and associated with the recorded activity.

For commerce-enabled sites, MetriXs documents revenue breakdowns by source, campaign and landing page.

Use consistent UTM parameters for links you control. A newsletter link might look like:

https://example.com/demo?utm_source=newsletter&utm_medium=email&utm_campaign=autumn_launch

Campaign labels should describe the campaign, not identify individual recipients. Avoid email addresses, customer IDs or other personal identifiers in UTM values.

For AI-driven discovery, recognised referrals from assistants such as ChatGPT or Perplexity can also provide useful source information. But not every click carries a usable referrer, and an AI referral report does not show every mention of your business inside an AI answer.

Attribution describes the observable journey. It is not a complete record of everything that influenced the customer.

Someone might read your newsletter on their phone, return directly on a laptop two days later and purchase. Without a persistent cross-device identifier, those interactions cannot simply be assumed to belong to the same person.

MetriXs describes its visitor identification as using a daily-rotating hash. This is a different measurement model from a persistent visitor ID stored for months. Do not interpret visitor counts as a durable list of individual people across reporting periods.

Cookieless analytics also remains subject to script blocking, network failures, browser restrictions and implementation errors. Removing cookies does not make measurement lossless.

No. They solve different problems.

Cookieless analytics measures website activity without relying on cookies.

Google Consent Mode adjusts how Google tags behave according to the consent state communicated by your website.

Google documents two approaches. Basic Consent Mode blocks Google tags until consent is granted. Advanced Consent Mode can send cookieless measurements while consent is denied, supporting modelling where applicable.

That does not make Consent Mode equivalent to an independent cookieless analytics tool. It also does not remove your responsibility to configure consent correctly.

Likewise, a signup recorded in MetriXs does not automatically become a Google Ads conversion or a Meta optimisation signal. Advertising-platform integrations, attribution and consent requirements need separate consideration.

See Google’s Consent Mode documentation for the distinction.

There is no universal answer based solely on the absence of cookies.

Applicable rules can cover other forms of device storage or access, and GDPR obligations can apply when personal data is processed. Audience-measurement exemptions also depend on jurisdiction, purpose and configuration.

The French regulator CNIL, for example, explains that some audience measurement can qualify for a consent exemption under specific conditions and notes that national implementations vary. See its guidance on audience measurement.

A responsible implementation minimises collected data, avoids personal information in event properties and URLs, documents the processing, and follows applicable consent requirements.

Your website may also still need a consent mechanism for advertising tags, embedded services or other technologies, even if your analytics setup does not require one.

Different tools can produce different totals without either being broken.

Common reasons include different event triggers, consent states, reporting time zones, visitor definitions, attribution windows and duplicate handling. Browser analytics may also miss orders completed without a successful return to your website.

Compare like with like: the same period, the same completion definition, and the same treatment of refunds, cancellations, tax and shipping.

Your backend order system should remain the source of truth for operational order records. Analytics helps you understand recorded acquisition and on-site behaviour; it is not a replacement for your accounting system.