Skip to content
Rechnungskit
Checkout · Conversion tracking
Playbook

Server-side tracking for Meta: Conversions API with a lean consent bar

Server-side tracking means the conversion event is sent to Meta from your server rather than from the buyer's browser; with Rechnungskit, from the payment webhook. You still need consent. The European Data Protection Board treats collecting a click ID from a tracking link as accessing the user's device (EDPB Guidelines 2/2023, paras. 50 f.), and for that § 25(1) TDDDG (German Telecommunications Digital Services Data Protection Act) requires consent. Rechnungskit therefore asks in the checkout with a slim bar as soon as tracking is active. Without a yes, nothing is stored and nothing is reported to Meta; the purchase still goes through.

The full path from click to report

The ad brings the buyer to the checkout. There, a slim bar asks whether measurement is allowed. Only with a yes is the click ID attached to the order, and only then does the server report the purchase to Meta after payment. Email, name and IP address stay with you by default.

Schritt 1:Meta ad
Click on the ad
  • fbclid is appended to the URL
  • Campaign UTM parameters
Click lands in the checkout
Schritt 2:Rechnungskit checkout
Consent, then purchase
  • Bar with Accept and Decline
  • Click ID on the order only with a yes
  • Purchase works either way
Payment confirmed
Payment confirmed
Payment provider
Payment confirmed
  • Webhook to Rechnungskit
  • Purchase event with fbc, amount, currency
  • Subscription start: Subscribe event
Conversions API: Purchase event from the server to Meta, only with consent and with an event_id against double counting.
What is sent after a yes
  • fbc
  • Amount
  • Currency
  • UTM
  • event_id

What server-side tracking is

Classic conversion tracking runs in the browser: on the thank-you page, a script (the Meta Pixel) loads, sets cookies and reports the purchase to Meta. With server-side tracking (at Meta, through the Conversions API, CAPI for short), your system sends the event itself, server to server. The buyer's browser is not involved.

For Meta, both routes are equivalent. A Purchase event from the Conversions API counts in campaign optimization, audiences and lookalikes just like one from the pixel. The difference lies in who sends, when the event is sent and which data goes with it.

The best moment to send is when the payment is confirmed: the payment provider's webhook. A pixel only reports that someone loaded the thank-you page. It cannot tell whether the payment went through.

Why the browser pixel sees less and less

Ad blockers and browser tracking protection block the pixel script entirely. Safari and iOS cut the lifetime of tracking cookies to a few days, so a purchase made a week later no longer traces back to the ad.

Then there is the moment of measurement. The thank-you page is the last page the buyer has to see. If they close the tab before the script loads, the purchase is missing. Meta's own documentation therefore recommends adding the Conversions API alongside the pixel. One thing the server route does not change: anyone who does not consent is not measured server-side either. The next section explains why.

Why the click ID needs consent too

The consent requirement comes from § 25(1) TDDDG (German), formerly TTDSG. Anyone who stores information on the user's device or reads it from there needs their consent. The only exception is what is strictly necessary for the service the user explicitly requested (para. 2 no. 2). A tracking cookie is the textbook case.

For a long time, server-side tracking was seen as a way around this because it sets no cookie. The click ID (fbclid) is only in the URL the buyer arrives with at the checkout. The European Data Protection Board, however, sees exactly the act the provision covers. Its guidelines on Art. 5(3) of the ePrivacy Directive, which § 25 TDDDG implements, say that a tracking link is stored on the device when distributed, at least in the browser cache (para. 50). The identifier in the link instructs the device to send it back, and whoever collects it gains access within the meaning of the provision (para. 51). See EDPB Guidelines 2/2023, version 2.0 of October 7, 2024, paras. 50 f..

Courts are not bound by the guidelines, and we know of no judgment on click IDs. Supervisory authorities do follow them, though. To be on the safe side, obtain consent before storing or passing on the click ID.

Flow · consent in the checkout
Decision first, then measurement
  1. Step 1Click on the adThe URL carries fbclid and UTM parameters
  2. Step 2Bar in the checkout: Accept or DeclineForm and pay button stay usable the whole time
  3. Step 3Purchase and paymentRechnungskit checks the decision when the order is submitted
  4. Step 4Report to Meta after paymentOnly if a yes is stored on the order
Buyer clicks AcceptClick ID and UTM parameters are attached to the order, along with the proof of consent. After payment, the Purchase event goes to Meta
Measured
Buyer declines or does not decideThe purchase goes through as usual. Neither click ID nor UTM parameters end up on the order, and Meta learns nothing
Not measured
The legal basis for measurement is consent under § 25(1) TDDDG and Art. 6(1)(a) GDPR. The cookie that remembers the decision falls under the exception in § 25(2) no. 2 TDDDG.

What lean consent looks like

Consent does not have to be a pop-up covering half the screen. In a checkout especially, that costs sales. Consent is valid if it is freely given, specific, informed and unambiguous (Art. 4(11) GDPR). A few practical rules follow from that:

  • A slim bar at the bottom instead of a window. The form stays visible and fillable, on phones too.
  • Two equally weighted buttons, Accept and Decline, in the same size and color. Declining should be just as easy.
  • No decision means no. Buying always works, with or without a yes.
  • A link to the privacy policy and an expandable section that names each provider and its purpose.
  • Store only the decision, not the identifiers. The cookie for the decision is strictly necessary for the requested service and therefore needs no consent itself (§ 25(2) no. 2 TDDDG).
  • Keep proof. If you rely on consent, you must be able to demonstrate it (Art. 7(1) GDPR). In practice, yes or no, the time, the text version and the named providers are stored on the order.

The cost is clear: some buyers decline, and Meta does not see those purchases. In return, you measure on a basis that holds up to scrutiny.

How attribution works without a tracking cookie

For Meta to attribute a purchase to an ad, it needs an anchor. With the pixel, that is the _fbc cookie, which the pixel builds from the fbclid URL parameter on the first page view. With server-side tracking, your server takes over: after consent, it attaches fbclid to the order, remembers the click time, and when sending builds the fbc parameter in the format fb.1.<click time>.<fbclid>, with the click time in milliseconds.

Two details decide the quality. fbc must contain the click time, not the purchase time; Meta checks the format, and a wrong timestamp costs you the attribution. And the click ID has to survive until payment. That is why it is attached to the order, not the device, so ad blockers and cookie lifetimes do not affect it.

Without a click ID there is no attribution. An organic purchase where nobody clicked an ad is not reported by default. If you want to report every purchase, you need a second anchor, usually the hashed email address.

Pixel and server in parallel, deduplicated by event ID

Many shops run both, the pixel in the browser and the Conversions API from the server. Then the same purchase reaches Meta twice. Meta counts it only once if both events carry the same event_id; it keeps one and discards the other.

The event ID therefore has to be fixed before sending and available to both sides. The server generates it from the order, and the pixel passes it as eventID. In the Rechnungskit checkout, the built-in Meta pixel does this on its own. For a pixel on your own thank-you page, Rechnungskit appends the ID to the return URL as the rk_event_id parameter.

What may be sent under the GDPR

Besides § 25 TDDDG, the GDPR (DSGVO in German) asks its own question: as soon as personal data goes to Meta, you need a legal basis under Art. 6(1) GDPR. The click ID can count as personal data, because the GDPR explicitly names online identifiers as a feature by which a person can be identified (Art. 4(1) GDPR). With the consent from the bar, you rest both on the same basis, Art. 6(1)(a) GDPR.

The Conversions API accepts a whole range of user data: email, name, phone, IP address, user agent, hashed or in plain text depending on the field. The more you send, the better Meta matches. The data-minimal route sends only what is needed to attribute the purchase to the ad: the click ID, the amount, the currency and the campaign UTM parameters. That is enough for campaign optimization.

If you want buyer audiences and lookalikes, you also send email and name as SHA-256 hashes. Meta requires normalized values for this, lowercase and without spaces, otherwise the hash does not match.

If you embed Meta tools, you may be jointly responsible with Meta for collecting and transmitting the data. The CJEU decided this for the embedded Like button (CJEU, judgment of 29.07.2019, C-40/17, Fashion ID). For joint controllers, Art. 26 GDPR requires an arrangement. Check with your data protection advisor which agreement Meta offers for this and whether it applies to your case.

How Rechnungskit does it in the checkout

Without active tracking, the Rechnungskit checkout runs no third-party script and shows no bar. As soon as you turn on Meta Ads, the Google tag or the TikTok pixel under Connections → Integrations, the checkout shows the consent bar: in the product checkout, the subscription checkout, on the shop page and on the thank-you pages. A privacy policy URL in your company details is required. If it is missing, tracking pauses and the integration card tells you.

  • Without a yes, Rechnungskit stores neither click IDs (fbclid, gclid, ttclid, msclkid) nor UTM parameters on the order and sends nothing to Meta. The webhook field attribution and the ad parameters on the return URL stay empty.
  • With a yes, click IDs and UTM parameters are attached to the order, together with the proof: decision, providers, version of the bar and time. After payment, the Meta Ads integration reports a Purchase event, and at subscription starts a Subscribe event with the plan amount of the first full period. Rechnungskit checks on the order at the moment of sending whether it may send.
  • Browser pixels for Meta, Google and TikTok load in the checkout only after the click on Accept. You enter only the IDs; there is no field for custom code. Rechnungskit turns off automatic form field analysis in code, as far as the provider allows. No pixel runs on the page with bank details for prepayment (Vorkasse) or in the customer portal.

Every report to Meta is listed in the log on the integration page. There you also see how many buyers consented in the last 30 days, as a plain count without personal data. Orders from before this change have no proof of consent and count as a no.

Setup and sample privacy policy text

How to set up tracking in the checkout:

  1. Under Settings, enter the URL of your privacy policy in the company details. Without it, no tracking starts.
  2. Under Connections → Integrations, connect Meta Ads with pixel ID and access token. Optionally, turn on the browser pixel there or enter the IDs for the Google tag and the TikTok pixel.
  3. Add every provider you have turned on to your privacy policy. A suggestion follows below.
  4. In Meta Events Manager and TikTok Events Manager, turn off automatic advanced matching. This setting lives with the provider; Rechnungskit cannot change it for you.
  5. Check the preview of the bar on the integration card and send a test event.

A suggested section for your privacy policy, translated from our German template (if your shop is German-language, use the German version). Adjust the square brackets and have the text reviewed, as this is not legal advice:

Measuring advertising performance in the checkout. For orders, we use the Rechnungskit checkout (checkout.rechnungskit.de). If you click "Accept" in the bar there, we store the identifier from the ad through which you reached us (for example fbclid) and the campaign parameters with your order. After payment, we transmit this identifier together with the amount, currency and an order identifier to [Meta Platforms Ireland Ltd. / Google Ireland Ltd. / TikTok Technology Ltd.] to measure the success of our advertising and to build advertising audiences. We then also load the respective provider's measurement script, which may set cookies. The legal basis is your consent (Art. 6(1)(a) GDPR, § 25(1) TDDDG). If you decline, we store and transmit none of this; you can order either way. We remember your decision for 180 days in a cookie on checkout.rechnungskit.de. You can withdraw your consent at any time with effect for the future: via the "Tracking settings" link at the bottom of the checkout or by deleting the cookies for checkout.rechnungskit.de. [Note on joint controllership with Meta under Art. 26 GDPR, if applicable.]

FAQ

You still need consent. The European Data Protection Board treats identifiers in tracking links as storage on the user's device and collecting them as access (EDPB Guidelines 2/2023, paras. 50 f.); for that, § 25(1) TDDDG (German) requires consent. In the Rechnungskit checkout, a slim bar appears automatically as soon as you turn tracking on. Without tracking, there is no bar.
Read more
Guide E-invoicing for B2C in Germany: does the mandate apply to online shops? Guide E-invoicing in Germany: the mandate explained for founders Guide Invoicing in a foreign currency in Germany: which exchange rate applies? (ECB, DATEV, OSS) Guide GoBD explained: principles, retention and what they mean for your invoices Guide Small-amount invoices in Germany (§ 33 UStDV): when the buyer's address can be left out Guide E-invoicing for small businesses in Germany (Kleinunternehmer): duties, exemptions, thresholds 2026 Guide The German cancellation button (§ 312k BGB): who needs it and how it works Guide The date of supply on German invoices: shipping date or payment date? Guide Leitweg-ID: what it is, how it is structured and how it gets onto the invoice Guide The OSS scheme explained: the €10,000 threshold, registration and an example Guide Deferred revenue for SaaS and online courses in Germany: when a pRAP is required Guide Proforma invoices in Germany: what they are for and why they are not invoices Guide Deferred revenue in German accounting (pRAP): definition, bookings and an example Guide Changing the billing address on a German invoice afterward: is it possible? (without a cancellation) Guide Correcting an invoice in Germany: which route for which error? Guide Shopify gift cards in Germany: gift card, discount code and store credit for VAT Guide Shopify invoices in Germany: what Shopify does, what is missing, what applies from 2027 Guide Shopware invoices: what Shopware 6 does on its own and what is missing Guide Stripe DATEV export: getting Stripe payments into DATEV as a booking batch Guide Booking Stripe fees in Germany: clearing account, reverse charge and Stripe Technology Europe Ltd Guide Stripe Invoicing in Germany: creating invoices, pricing and e-invoicing Guide Stripe invoices with payment terms as e-invoices: bank transfer to the Stripe IBAN Guide Stripe invoices in Germany: what Stripe Invoicing and Billing do, what is missing, and what applies from 2027 Guide Shipping costs and VAT in Germany: 7%, 19% or tax-exempt? Guide The German withdrawal button (§ 356a BGB): mandatory since June 19, 2026 Guide WooCommerce DATEV export: options, file format and account mapping Guide WooCommerce invoices in Germany: plugins, mandatory details, e-invoicing Guide XRechnung vs ZUGFeRD: the XRechnung format explained Guide Payment terms on invoices in Germany: rules, due date calculation and wording Guide ZUGFeRD explained

Rechnungskit is not a tax advisory or law firm. This article explains general principles and does not replace advice from a tax advisor (Steuerberater, § 5 StBerG) or a lawyer (§ 3 RDG). Rechnungskit is built for businesses based in Germany and prepares documents, tax rates and bookings automatically. How your specific case is treated remains your decision, ideally together with your tax advisor or a lawyer.

Every invoice automatically as a valid e-invoice.

Connect your payment provider and we take care of format, validation and archive. Start for free in test mode.

Try it now
de en