LinkedIn Insight Tag and Conversions API, Built Server-Side

If your checkout finishes through an instant EFT redirect, using Ozow, PayFast, Peach or Yoco, your browser-side purchase event is under-reporting. We have not yet opened a South African DTC account where the Insight Tag total matched settled orders in the payment provider for the same period. The repair is not a better tag. It is a server event fired from the payment webhook, deduplicated against the browser event, and reconciled monthly against settlement. What gets built: A first-party event spine your own infrastructure owns. Server-side Google Tag Manager on a subdomain you control, or a small Node worker on the same VPS if you would rather not run a container. Every conversion gets one definition, an event id, a value, a currency and a timestamp, and it is sent from one place to LinkedIn's Conversions API and, on the same call, to Meta and X where those accounts exist. One source of truth beats three tags that disagree in a meeting. Identity, which is the actual job: LinkedIn matches on hashed email and on li_fat_id, its first-party click identifier. That identifier has to be captured on landing, stored on the lead or order record, and sent back with the event, including three months later when the quote is finally accepted. Most implementations skip the storage step and then blame match rates. We capture on landing, persist into your CRM or database, hash emails lowercased and trimmed with SHA-256, and read the match rate Campaign Manager reports back before we call the work finished. Deduplication and attribution windows: Browser and server events carry the same event id against the same conversion rule, so LinkedIn counts one. Windows get set deliberately rather than left as they arrive. On quote-driven industrial accounts we hold a 30-day click window and cut the view window to one day, because a view-through credited on a nine-month purchase is a story, not evidence. Offline conversions: For a manufacturer the event that matters is not the form. We map CRM stage changes, typically qualified enquiry, quote issued and quote accepted, into the same API with the original click identifier and the deal value attached, so the campaign that produced a R400,000 order is visible next to the one that produced forty datasheet downloads. Built against HubSpot, Pipedrive and Salesforce directly; anything else we build against its API. Consent and the law: Events carry a consent state as a flag rather than being dropped silently, so your own analytics still shows the traffic and you can see what consent is costing you. We write the data map: which field is collected, where it is hashed, what leaves your servers, who receives it and where it is stored, for POPIA and, on EU traffic, GDPR. Your counsel signs it. We do not draft policy and we do not act as your information officer. Not included: Checkout rebuilds, CRM re-implementation, consent platform licences, or analytics reporting layers. We also do not sell a tracking audit as a standalone deliverable. There is no version of this engagement where we point at the problem and leave. How you know it worked: Three numbers at handover. Server events received against orders settled by your payment provider for the same window. The match rate LinkedIn reports on those server events. The duplicate rate between browser and server. We agree the acceptable range for each at kickoff, and if any of the three sits outside it we keep working at no change to the fee. Who should not buy this: Anyone who cannot give us a place to run server-side code, and anyone whose conversion volume is low enough that the platform will never optimise on it regardless of how clean the signal is. In that second case the answer is a different bidding strategy, and we will say so on the first call.