GA4 Property Rebuild and Migration for DACH Ecommerce

GA4 will not match your shop backend, and a correct GA4 build does not try to. Across the DACH shops we have measured, a consent banner with a genuine reject button leaves analytics storage granted on roughly 60 to 80 percent of sessions, and no amount of tag work recovers the rest. The property's job is to explain behaviour and channel mix. The revenue ledger stays in the shop and the ERP, and we set that expectation in writing before we build anything. The deliverable is the event schema, not the property: We write a measurement specification first: event names, parameters, types, allowed values, which system emits each one, and what question each exists to answer. A beauty shop needs shade and format on every item; a furniture shop needs delivery lead time, assembly option and whether the item sits on a long-lead supplier order, because those decide whether a slow checkout is a tracking problem or a logistics one. Everything not tied to a question gets cut before it reaches a tag. What the build includes: Property and stream architecture, including consolidation when six properties have accumulated and nobody knows which one the board reads. Consent Mode v2 in advanced mode, with defaults denied and set in the page head before the container loads, ad_user_data and ad_personalization mapped to the actual CMP categories rather than to all-or-nothing. Key events aligned to what the ad platforms are optimising towards. Referral exclusions for the payment domains — Klarna, PayPal, Mollie — because a PSP redirect otherwise starts a new session and hands your paid traffic to referral. Internal traffic filtering that survives a dynamic office IP. Cross-domain configuration between shop, magazine and any headless front end. Data retention set to 14 months on day one, since it cannot be applied retroactively. BigQuery export configured at the start, both daily and streaming, with the free daily export ceiling of one million events understood in advance rather than discovered when a campaign spike suspends the export. Reporting dimensions designed against the 500,000-row cardinality limit, so the report you plan to read weekly does not resolve to "(other)". Migrations we take: Moving from a setup that was rushed, from a property whose event names cannot be repaired in place, or onto a server-side data stream. Historical Universal Analytics data is archived in BigQuery and kept clearly separate. We will not stitch it into GA4 to produce a continuous line, because the two systems counted sessions differently and the joined chart is a lie that someone will later put in a board pack. What we refuse: We will not tune a property until it agrees with a previous tool's numbers. Chasing a match between two differently defined systems is a month of work that ends in a false sense of accuracy. We will not set Google Signals as the reporting identity by default. Thresholding then removes rows from demographic and behavioural reports without saying which, and analysts read the remainder as complete. We will not present modelled conversions as measured ones. Where modelling is on, the report labels it. Who this is not for: Teams who need a single number that reconciles to the cent with finance; that is a warehouse project, and we would rather tell you that now. Shops with no development capacity to implement a data layer — the specification is worthless if nobody can ship it. Anyone who wants the property live this week and the definitions written later. Working in English or German, including the specification document, which your developers and your data protection officer both have to be able to read.