CONNECTIONS / Snowflake / Snowflake to LinkedIn Offline CAPI
Snowflake's closed-deals table, credited back to LinkedIn.
A LinkedIn-sourced deal often closes long after any pixel window has aged out. Signals reads the closed-deals table your warehouse already maintains and matches each row to the original ad by hashed business email instead.
- ● snowflake → linkedin.offline_capi :: live
- > sync table CLOSED_DEALS_LEDGER rows=9,140
- hash sha256(business_email)
- route linkedin.offline_capi conversion=closed_won
- ✓ delivered · pipeline attributed
WHAT THIS ENABLES
Snowflake to LinkedIn Offline Conversions API
Snowflake to LinkedIn Offline Conversions API reads a closed-deals table from your warehouse and posts the rows to LinkedIn's Conversions API, matched on hashed business email, so a B2B deal that takes months to close still attributes back to the campaign that started it.
- Rows already sitting in the CLOSED_DEALS_LEDGER table, matched back to the LinkedIn ad that opened each deal no matter how many quarters passed in between.
- LinkedIn optimization informed by the same closed-deals table your revenue reporting already reads.
- The same warehouse read you already run for other ad platforms, extended to LinkedIn.
The click, the conversion, and the credit.
The conversion happens off LinkedIn, away from any pixel. Here is how Snowflake closes the loop.
Built for the teams that own the number.
Teams already reading that table for other ad platforms who want LinkedIn included.
From kickoff to verified events.
-
Connect
A read-only Snowflake role scoped to the closed-deals table and the business email column LinkedIn matches on.
-
Map
Whichever column marks a deal as closed, matched once to a LinkedIn offline conversion definition in the visual mapper.
-
Deliver
Delivery to LinkedIn's Conversions API, deduped against rows the sync has already sent.
What changes when the CSV goes away.
| Capability | Manual CSV upload | Datahash |
|---|---|---|
| Reporting | Offline sales sit in a separate export, reconciled by hand. | Revenue counted in the same Offline CAPI reporting as web conversions. |
| Deduplication | A re-uploaded file risks counting the same conversion twice. | Deduped delivery, so a resent record never counts as a second conversion. |
| Match visibility | Match quality is a guess until the numbers look off. | Match rate reported per upload, tied to the source event set that produced it. |
| Effort and latency | An analyst exports and uploads on a manual cadence. | Server-side and automatic the moment Snowflake records the event. |
What Offline CAPI actually receives.
- ● signals :: event payload
- > POST /conversionEvents source=snowflake.CLOSED_DEALS_LEDGER
- conversion "urn:lla:llaPartnerConversion:623914"
- conversionHappenedAt 1784456700000
- user.userIds [{ idType: "SHA256_EMAIL", idValue: "b19e04…" }]
- ✓ accepted · conversionValue 52000 USD
Adjacent moves on the same stack.
from Snowflake
Snowflake to Google OCI
Snowflake to Google Offline Conversion Import reads a warehouse table where GCLID capture…
Learn morefrom Snowflake
Snowflake to Google Store Sales
Snowflake to Google Store Sales reads in-store transactions directly from your Snowflake…
Learn more
same use case
ActiveCampaign to LinkedIn Offline CAPI
ActiveCampaign to LinkedIn Offline CAPI: Signals reads your ActiveCampaign contacts and…
Learn moregeneric
LinkedIn Offline CAPI
Datahash routes offline outcomes, like closed deals from your CRM, to LinkedIn with hashed…
Learn moreAsked on almost every call.
Our closed-deals table only gets rows months after the original LinkedIn click. Does attribution still work?
Yes. Matching happens on hashed business email rather than a click ID, so nothing depends on a cookie or pixel window still being alive by the time the deal lands in the table. A row that closes six months after the original ad click still credits that campaign, provided the business email on file matches what LinkedIn captured at the click.
What other tables besides closed deals can feed LinkedIn's offline pipeline?
Any table your warehouse maintains as a distinct milestone can be mapped, though a closed-deals table is the most common starting point because it is the outcome LinkedIn's bidding optimizes toward. Some B2B teams also read an earlier qualified-opportunity table to give LinkedIn a faster signal while the closed-deal feed builds volume.
Does the closed-deals table need to exist specifically for this sync?
No. Revenue reporting is usually already pulling from this same table, so Signals reads it exactly as it stands rather than asking for a purpose-built copy. A later change to the table's shape means updating the mapper once, and the next scheduled read carries on from there.
NEXT STEP