SealMetrics
Use case — Conversion tracking

Conversion tracking. No cookie, no banner.

How to track every conversion that matters — purchase, form submit, lead, signup — on an EU site without a cookie banner, without per-user identifiers, and without losing the platform-side pixels that still power Google Ads and Meta optimisation.

The two-layer model

The clearest way to think about conversion tracking after the cookie collapse is to separate the two jobs cookies used to do badly together. Measurement (counting real events for revenue decisions) and optimisation (sending signals to ad platforms so they bid better). They are different layers, with different identifier requirements, different consent profiles and different failure modes.

Measurement layer

The number the CFO sees. Aggregate, anonymous, no cookie, no identifier, no consent banner. Captures 100% of observed conversions on the full population. Reconciles with the eCommerce backend on order_id.

  • SealMetrics (this is the layer the page describes)
  • First-party server-side from pixel.yourdomain.com
  • Outside ePrivacy / GDPR consent scope

Optimisation layer

The signal the bidder needs. User-level data sent to Meta and Google for ad optimisation. Requires hashed email or phone, sets first-party cookies, lives inside the consent banner because of the identifier.

  • Meta Conversion API + Meta pixel
  • Google Ads pixel + Enhanced Conversions
  • Still requires consent for its cookies

Both layers run from the same dataLayer push — one event fires the SealMetrics pixel and the platform pixels in parallel. The CMP gates only the platform pixels; the SealMetrics pixel runs regardless of consent decision.

Conversion types covered

What can be tracked without cookies? In short: any event the browser fires or the server receives. The taxonomy below covers the common cases — none of them require a cookie or a banner.

eCommerce purchase events

Native coverage on Shopify, WooCommerce, Magento, PrestaShop, BigCommerce, Salesforce Commerce Cloud.order_placed fires server-side on the order-confirmation hook with revenue, currency, line items and order_id. See the per-platform setup on /platforms/shopify and /platforms/woocommerce.

Lead and form-submission events

Any DOM form submit fires a form_submitted event with the form ID and the channel metadata of the page. For a typical lead-gen site this covers contact, demo, newsletter, callback. No PII captured from the form itself (name, email, phone stay on your form processor).

SaaS signup and trial events

For PLG SaaS sites, signup_completed fires on the post-signup confirmation page. The trial-to-paid conversion fires on the first paid charge via your billing webhook. Channel attribution rolls up against the SealMetrics dataset; user-level in-product analytics live in Mixpanel or Amplitude alongside.

Custom and micro-conversions

Scroll depth, time-on-page thresholds, video plays, PDF downloads, custom button clicks — any browser event the team flags as a conversion can be configured in the workspace. Aggregate counts only; no per-user behavioural sequencing.

Offline conversions

Phone-call bookings, in-store purchases and consultation outcomes get joined via a business key — typically a unique discount code shown on-site and used at the point of conversion. The offline-conversion API ingests the event with that business key, which ties it back to the source channel on the on-site visit. SealMetrics does not stitch sessions to users; the join key comes from your business logic.

What stays alongside

Conversion tracking without cookies is not a complete replacement for everything cookie-based pixels used to do. Three layers stay in place — each for a different reason:

  • Meta Conversion API + Meta pixel. Feeds the Meta bidder for ad optimisation. User-level data, hashed identifiers, requires consent. Runs inside the banner.
  • Google Ads pixel + Enhanced Conversions. Feeds the Google Ads bidder. Same shape as Meta. Runs inside the banner. Often pairs with GA4 conversion goals for legacy consistency.
  • Product analytics (Mixpanel, Amplitude, PostHog). User-level in-product event analytics behind authentication. Lives inside the logged-in app, not on the marketing site. Different category, different consent profile.

The right setup is parallel: SealMetrics on the measurement layer (always firing, always counting), the platform pixels on the optimisation layer (firing only when the visitor consents to the cookie banner). Decisions are made on the SealMetrics number; bidding is done on whatever signal the platforms accept.

Related reading

Use case

Revenue attribution

Last-click on 100% of conversions — what attribution looks like with complete data.

Use case

GA4 migration plan

The 30-day parallel-run for moving conversion measurement off GA4.

Pillar

Cookieless analytics

The architecture that makes the measurement layer possible — first-party server-side without identifiers.

Common questions

Can I track form-submission conversions without cookies?
Yes. Form submissions, button clicks, scroll depth, video plays — any DOM event — are captured server-side on a first-party endpoint. The pixel records the event with channel and landing-page metadata; no cookie is read or written. For a typical lead-gen site, this covers contact-form submissions, demo-request submissions and newsletter signups without any identifier on the device.
Does it work for offline conversions?
Partially. Offline conversions (phone calls, in-store purchases) need to be ingested via the offline-conversion API with whatever business identifier ties them back to the on-site visit — for example, a unique discount code shown on-site and used in-store. SealMetrics does not stitch sessions to users, so the join key comes from your business logic, not from the tracker.
What about Meta Conversion API and Google Enhanced Conversions?
These are platform-side server-to-server pipes for sending conversion data back to Meta and Google for ad optimisation. They still require user-level data to be sent (hashed email, hashed phone). SealMetrics does not feed them — Meta Conversion API and Google Enhanced Conversions remain a separate concern, typically wired through your tag manager or via your CRM. SealMetrics handles the measurement side; the ad pixels handle the optimisation side.
Will my paid-ad platforms still optimise correctly?
Yes, as long as the platform pixels keep firing. Meta and Google pixels run as a separate layer with their own consent and their own cookies — they exist to feed the bidder, not to measure your business. SealMetrics replaces the measurement layer (the number you decide on); the platform pixels stay for their optimisation purpose. The right setup is parallel: pixels for bidding, SealMetrics for truth.
How do I handle GA4 conversion goals during the transition?
Keep them. GA4 conversion goals power Google Ads conversion import — that integration is valuable independent of measurement accuracy. The recommended pattern is: SealMetrics records the conversion event for measurement (channel attribution, revenue reporting), GA4 records the conversion event for Google Ads bidding. Both layers run in parallel from the same dataLayer push. The 30-day parallel-run is documented on the GA4 migration use-case page.
Does it support custom conversion definitions?
Yes. Beyond the standard eCommerce events (add_to_cart, begin_checkout, purchase), any custom event from your site can be configured as a conversion in the SealMetrics workspace — including scroll-depth, time-on-page thresholds, micro-conversions (PDF downloads, video starts) and any element your team flags. Conversions are aggregate counts; no per-user behavioural sequencing.

Set up complete conversion tracking. Without the banner.

Book 30 minutes with the founder. We map your existing conversion goals to SealMetrics live, configure custom events, and confirm the platform pixels stay intact.

Start FREE Trial →Book a demo

Built by a founder · supported by a founder · EU-hosted by design