E-commerce without cookies – how to prepare a store?

Cookieless e-commerce with 3rd‑party cookies requires a change in approach to analytics. Less “user tracking” and more work with 1st‑party data and order-related events. The key remains maintaining reliable measurement of sales and channel performance when some users do not consent to marketing and analytics. This is possible, but it requires a clear definition of which business decisions are to be powered by data and which metrics will remain stable in a restricted tracking environment. In practice, simple, well-defined KPIs and data quality control work best, so that reports do not “drift apart” between tools. In this section, I show how to select KPIs and prepare measurement so that it is operationally useful, rather than just “nice in reports”.

measurement strategy without cookies: key KPIs for e-commerce

A measurement strategy without cookies should start with selecting 5–8 KPIs that can be measured reliably without advertising identifiers. At the outset, it is worth clarifying which questions the measurement is meant to answer. Which channels drive sales, where users drop out of the funnel, and which categories have a margin problem. If profitability is the priority, it is better to include ROAS by margin (e.g. after delivery and returns costs), rather than revenue alone. Without such a map of business decisions, KPIs quickly turn into “metrics for metrics’ sake” and do not translate into better actions.

• Revenue, number of transactions, AOV (average order value), CR (conversion rate)
• Share of returning customers, CAC from blended models, LTV calculated on CRM data
• Data quality metrics: % of orders with an assigned source and % of events with a missing product parameter

You will only maintain KPI consistency if you document the definitions and the metrics glossary (e.g. who counts as a “returning customer”, what you consider an “abandoned basket”, and how you calculate returns). This approach reduces discrepancies between GA4, the store system and BI, which in practice can reach 10–30%. At the same time, plan for limited consent scenarios. Full consent (full tracking), only essential (minimal measurement), and no consent (aggregates and server logs). In the cookieless world, KPIs must work in each of these modes; otherwise reporting will start to depend more on consents than on actual sales.

1. 01Choose 5–8 KPIsReliably measurable without identifiers.
2. 02Analyse the funnelIdentify where users drop out.
3. 03Measure profitabilityPrioritise ROAS by margin, not revenue alone.
4. 04Document definitionsReduce discrepancies, create a metrics glossary.

Key takeaways: Without precise definitions and a map of decisions, KPIs become just empty metrics rather than a tool for better actions.

how to build a 1st-party data architecture and manage consent

You build a 1st-party data architecture by combining consent management (CMP), persistent 1st-party identifiers and a controlled flow of events to analytics and marketing tools. In practice, it is worth starting with a CMP compliant with TCF 2.2 and GDPR (e.g. Cookiebot, OneTrust, Didomi or Piwik PRO Consent Manager) and checking whether tags are actually blocked until consent is given. A CMP cannot be “just a banner” — it should block the firing of tags and record the consent signal (audit trail). For Google Ads/GA4, it is also worth considering Consent Mode v2 (including ad_storage, analytics_storage, ad_user_data, ad_personalization), which passes information about restrictions and allows conversions to be modelled when consent is absent.

Collect data in line with the privacy by design principle, that is, with a clear separation of the “essential” layer from marketing and analytics. Define the minimum scope of data needed for the store to function without consent (basket, login, security, payment, language preferences), and do not use it for ad profiling without an appropriate legal basis. Design the 1st-party identifier around the customer account or e-mail (hash) created only after a user action (e.g. login or newsletter signup), because this is a more stable solution than 3rd‑party cookies. For greater control over data, implement server-side tagging (e.g. server-side Google Tag Manager or alternatives such as Stape, Piwik PRO), and validate the event schema (names, parameters, types) with rules to avoid breaking reports with inconsistent parameters.

e-commerce analytics: GA4 in limited mode

GA4 in limited mode can still be useful if you base measurement on a full set of e-commerce events and consistently take care of transaction parameters. Configure e-commerce events and make sure that purchase includes at least transaction_id, value, currency and item_id, because this is a condition for consistent sales reporting. When consent is missing, GA4 uses modelling, so results may differ from the store’s system data. Treat GA4 as a tool for analysing trends and behaviour, not as a sales “accounting system”.

You will maintain consistency in GA4 reports when you regularly compare them with back-office data and correct implementation discrepancies. The most common sources of problems are missing transaction parameters, inconsistent product identifiers and differences arising from consent restrictions and modelling. In practice, this means that operational decisions can be based on the direction of change (e.g. funnel, conversions), while sales figures should be verified against store data. This setup allows you to use GA4 despite tracking limitations, without overestimating the precision of attribution in reports.

1. 01Configure e-commerce eventsFull set, all transaction parameters.
2. 02Key data in PurchaseRequired: transaction_id, value, currency, item_id.
3. 03Trend analysis toolDo not use as sales accounting.
4. 04Ongoing verification and correctionCompare with back office, eliminate implementation errors.

Maintain consistency in GA4 reports through full e-commerce event configuration and regular comparison of data with the store system, despite consent and modelling limitations.

Marketing personalisation without 3rd-party cookies

Marketing personalisation without 3rd-party cookies is based on 1st-party data (purchases, consents, on-site behaviour) rather than tracking users across other services. In practice, it is worth building RFM segments (Recency, Frequency, Monetary) and cohorts based on transaction history, because they provide a stable foundation for campaigns in owned channels. For example, the “VIP” segment can be defined as 3+ orders and >600 zł in 180 days, to feed communication in email/SMS and recommendations without the need to use advertising cookies. The biggest advantage here comes from “value exchange”: a loyalty programme and log-in, which increase the proportion of identifiable 1st-party customers.

Instead of classic retargeting, it is better to strengthen channels that are less sensitive to browser-side changes, namely email and SMS, as well as automations in tools such as Klaviyo, Bloomreach, Emarsys or SALESmanago. In paid campaigns, it makes sense to shift the emphasis to context: keywords in Google Search, placements, topics and intent, and the product feed in Performance Max. At the same time, you can use product recommendations without cross-site tracking, based on on-site behaviour and transaction history (“frequently bought together”, “similar products”, “complete the set”), for example in Nosto, Synerise, Bloomreach or Recombee. With your own audiences (Customer Match/Custom Audiences), data hygiene is key: normalising numbers, removing unsubscribes and updating lists every 7–30 days.

Store technology: cookieless-ready integrations

Cookieless-ready integrations in e-commerce most often mean a hybrid model in which key conversions (e.g. purchase) are sent server-side, and some browser events are only fired after consent has been obtained. In practice, implementing server-side Google Tag Manager (sGTM) or alternatives (e.g. Stape, Piwik PRO) gives you greater control over what is sent to vendors and when, while also reducing data loss caused by browser blocks. In the case of sGTM, it is worth planning the architecture and hosting in advance (e.g. Google Cloud Run or App Engine), as well as a custom subdomain (e.g. s.example.com) for better reliability. If you care about stable conversion measurement in ads, server-side sending is usually one of the highest-ROI investments in cookieless.

The technical quality of data largely comes from standardising e-commerce events and product parameters. It is worth maintaining consistent item_id (SKU), item_name, item_category, price, quantity, as well as coupons and discounts at item level. Deduplication and idempotency are also essential, meaning the consistent use of event_id for events sent from the browser and server (e.g. a UUID generated in checkout and passed to the webhook), because otherwise it is easy to double-count purchase. Platforms differ in their integration points (Shopify: webhooks and pixel sandbox. WooCommerce: most often plugins or custom endpoints. Magento/Shopware: advanced events), so it is best to establish where order webhooks and transaction identifiers can be connected most easily. For security and order after implementation, it is a good idea to limit vendors and consider Content Security Policy (CSP) and Subresource Integrity (SRI), and to monitor integrations through conversion delivery logs (HTTP statuses, delays, errors) and retry for webhooks, using for example Sentry, Datadog/New Relic or Cloud Logging.

Cookieless-ready also covers performance and testing. The number of tags should be limited, scripts loaded conditionally after consent, and some events moved server-side to reduce browser load. In practice, improving LCP from 3.5 s to <2.5 s often raises CR by several to a dozen percent on mobile, which makes it easier to offset weaker remarketing. A/B tests can be run using tools based on 1st-party data and events (Optimizely, VWO, AB Tasty) or carried out in your own application together with warehouse analysis, provided the variant is assigned consistently and measurement is based on server-side conversions. Since remarketing will be less predictable, UX on the site becomes more important, including speed, clear delivery costs, a shorter checkout and a clearly defined free-delivery threshold.

1. 01Hybrid modelPurchases sent server-side, browser after consent.
2. 02sGTM implementationGreater data control, less loss due to blocks.
3. 03Stable measurement & ROIHigh investment in data reliability.

Server-side sending is a key cookieless investment, ensuring stability and data quality.

Law and GDPR: compliance and communicating privacy value

Cookieless compliance with GDPR starts with clearly assigning legal bases to individual processes and describing this in the documentation. You need to establish which activities rely on consent (marketing/ads), which on a contract (order fulfilment), and which on legitimate interest (e.g. security and basic analytics — depending on interpretation and risk). Since in the EU the answer to the question “does analytics always require consent?” is often disputed, it is worth adopting a risk-based approach and describing it in the record of processing activities and the privacy policy. What is crucial is that the technical implementation (tag blocking) remains consistent with what you declare in your documents and communications.

Up-to-date cookie and privacy policies should explicitly describe the tools used, their purposes, providers, transfers outside the EEA, retention, and how consent can be withdrawn. For solutions such as Meta CAPI or Google Enhanced Conversions, it is worth clarifying the data categories (e.g. email hash), the purpose (measurement/attribution) and the activation condition (only after consent), in line with the data minimisation principle. It is also a good idea to verify data processing agreements (DPA) with vendors (e.g. Google, Meta, Klaviyo, Hotjar) and transfer bases (SCC, possibly TIA), because the lack of a DPA is one of the most common gaps uncovered in audits. Documents and DPA are part of being “cookieless-ready” just as much as tags and integrations.

The consent withdrawal mechanism should be as simple as giving consent and should remain constantly available in the store interface. It is worth adding a clear “Change consents” link in the footer and enabling granular choices (analytics, marketing, personalisation) in line with the CMP, and after withdrawal immediately stopping tags and updating systems (e.g. mailing lists). You should also define DSAR procedures (access, rectification, erasure): how data is searched by email/customer ID in the store, CRM, email tools and warehouse, and how identity is verified. In practice, the deletion pipeline may include, among other things, Klaviyo/Emarsys, the reviews system, the helpdesk (Zendesk) and backups according to the schedule.

It is better to base privacy communication on a concrete “value exchange” rather than on scaring users with a banner. It is worth showing users tangible benefits: better recommendations after logging in, faster checkout, returns history and personalised discounts for programme participants. At the same time, limit the number of third-party scripts to those that genuinely deliver value, because every vendor increases legal and security risk and slows down the site. After every theme, app or tag change, run a mini-audit: are tags blocked without consent, are you not sending PII in the URL, and is the purchase event not duplicated, using cookie scanners, GTM preview mode and request analysis in DevTools.

how to optimise campaigns without cookies: strategies and tools

You optimise cookieless campaigns by shifting the weight of decisions from user-click attribution to 1st-party signals, server-side measurement and statistical models. You have to accept that tracking individual users will weaken, and mixed attribution and incrementality tests will become more important. Operationally, use simple reporting models (e.g. last non-direct click), and adjust budgets based on channel cost, revenue and corrections for returns in the data warehouse. The most important step is establishing which decisions you make on aggregated data (e.g. MMM), and which on 1st-party data (e.g. CRM segments).

A stable foundation for optimisation is server-side measurement of the purchase conversion after payment confirmation. In practice, it is worth sending conversions from the backend to reduce the impact of browser blocking and ad blockers, e.g. a webhook from the e-commerce platform → sGTM endpoint → GA4 + Google Ads + Meta CAPI. In Google Ads, enable Enhanced Conversions and pass hashed data (email/phone) only after obtaining consent, to improve conversion matching while meeting the information obligation and data minimisation requirements. In the Meta ecosystem, implement Conversion API server-side with event_id deduplication, because without it results can be inflated by double counting events from the pixel and the server.

Optimisation in a cookieless world requires reports to include returns, cancellations and real profitability, not just revenue. Add returns (RMA), cancellations, discounts, shipping costs and payment fees to the pipeline, so campaigns do not look better than they really are. Where user identification is missing, join sources via UTM/click ID, and close the rest with models and incrementality tests. If you make decisions on “dirty” data (without returns and costs), optimisation will systematically push budget into the wrong places.

The tools for controlling and scaling campaigns without cookies are first and foremost a warehouse + dashboards, as well as monitoring data loss. Set up alerts when the number of purchases in GA4 vs the store drops (e.g. a difference >7% for 2 days) or the share of (direct)/(not set) grows, using Looker Studio + BigQuery, Metabase or Grafana. For larger budgets, consider Marketing Mix Modelling (e.g. Robyn from Meta, Meridian from Google) and incrementality experiments (geo-split or holdout), which answer the question of whether ads genuinely increase sales without full tracking. This way, optimisation is based on sales uplift, not just the conversion attribution in the platform.

monitoring and A/B tests in a cookieless environment

Monitoring in a cookieless environment means continuously detecting data loss and integration errors before they translate into poor budget decisions. Enable alerts when the number of purchases in GA4 vs the store drops (e.g. a difference >7% for 2 days) or the share of (direct)/(not set) grows, because these are typical symptoms of problems after changes to tags, the theme or the CMP. Use Looker Studio + BigQuery, Metabase or Grafana for dashboards and notifications so you can spot trends faster than in the ad platforms alone. The most practical monitoring is the kind that compares “tool” data with back-office data and automatically reports deviations.

Implementation validation tests should confirm that the measurement matches the store’s data and that no duplication appears after moving to server-side. It is worth preparing a validation checklist covering: matching the number of transactions between the store and the analytics tool (ideally a difference of <2–5%), correct currency, tax, shipping and discounts, as well as the absence of a duplicate purchase (this is a common error after server-side implementation). It is best to run tests on staging and on a small amount of production traffic, so you can catch issues before they land at the peak of sales. After changes to the theme, apps or tags, run a mini-audit: check whether tags are being blocked without consent, whether you are sending PII in the URL, and whether purchase is being duplicated, using cookie scanners (e.g. Cookiebot scanner), GTM preview and DevTools.

A/B tests in a cookieless approach remain reliable, provided they rely on server-side conversions and maintain consistent variant assignment. For experiments, choose tools that work on 1st-party data and events, such as Optimizely, VWO or AB Tasty, and with smaller budgets run your own tests in the app and analyse the results in the warehouse. The most important thing is consistent variant assignment (e.g. within a session or after login) and assessment based on a stable purchase signal. When you combine unstable sessions with unconfirmed conversions in tests, the results may reflect tracking limitations to a greater extent than the real impact of the change.

• Log conversion deliveries (HTTP statuses, delays, errors) and set up retries for webhooks so you do not lose purchases when failures occur.
• Verify server-side event deduplication (fixed event_id) to avoid duplicate transactions.
• Compare store vs analytics transactions and stick to the deviation threshold (ideally <2–5%), and if the gap is larger, return to the implementation.
• Monitor growth in (direct)/(not set) and drops in purchase in GA4, as these often signal a problem with tags, CMP or payment integration.
• After each change, run a mini-audit of tag blocking without consent and a request check in DevTools.