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.
- fbclid is appended to the URL
- Campaign UTM parameters
- Bar with Accept and Decline
- Click ID on the order only with a yes
- Purchase works either way
- Webhook to Rechnungskit
- Purchase event with fbc, amount, currency
- Subscription start: Subscribe event
- 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.
- Step 1Click on the adThe URL carries fbclid and UTM parameters
- Step 2Bar in the checkout: Accept or DeclineForm and pay button stay usable the whole time
- Step 3Purchase and paymentRechnungskit checks the decision when the order is submitted
- Step 4Report to Meta after paymentOnly if a yes is stored on the order
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 fieldattributionand 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:
- Under Settings, enter the URL of your privacy policy in the company details. Without it, no tracking starts.
- 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.
- Add every provider you have turned on to your privacy policy. A suggestion follows below.
- 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.
- 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
- [1] Meta for Developers: Conversions API (overview)
- [2] Meta for Developers: fbp and fbc parameters (format, click timestamp)
- [3] Meta for Developers: deduplicating pixel and server events (event_id)
- [4] § 25 TDDDG: protection of privacy in terminal equipment (gesetze-im-internet.de, German)
- [5] EDPB: Guidelines 2/2023 on the technical scope of Art. 5(3) of the ePrivacy Directive, version 2.0 of October 7, 2024, paras. 47 to 51
- [6] General Data Protection Regulation (EU) 2016/679, Art. 4, 6, 7 and 26 (EUR-Lex, German version)
- [7] CJEU, judgment of 29.07.2019, C-40/17 (Fashion ID)
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