The problem this solves
Most companies have never sent LinkedIn a single conversion event, which means the algorithm has spent the whole relationship guessing. The history that would educate it sits in a spreadsheet somewhere: the deals list, the export from the old CRM, the tab where sales tracks wins. Getting that history into LinkedIn means understanding the Conversions API, the hashing requirements, and the 90-day window rule - a small engineering project nobody sponsors for a marketing hygiene task.
So the backfill never happens, and every campaign optimization decision runs on click data alone. The irony is that the first event batch is the highest-leverage one: going from zero outcome signal to any outcome signal changes what the optimizer can see. The spreadsheet was always enough; only the plumbing was missing.
This mission is the plumbing. Hand it the file - emails, dates, values in any reasonable shape - and it maps rows to your conversion rule, validates what LinkedIn will actually accept, hashes every address at staging, and parks the batch for your approval with an honest account of what was set aside and why.
How the mission runs
- Read the file as it is. Attach or paste the CSV. Columns are inferred - email, date, value, whatever naming the sheet uses - and ambiguities are asked about rather than guessed at.
- Validate against the rules of the road. LinkedIn accepts events up to 90 days old. Rows older than the window, with unparseable dates, or with malformed emails are separated into a set-aside list with per-row reasons - reported, never silently dropped.
- Map to the conversion rule. Valid rows become events against the rule you name (or the mission lists your rules and asks). Deal values ride along where present, so the backfill carries revenue weight rather than bare counts.
- Hash and stage. Every email is SHA-256 hashed immediately - the approval row and everything downstream holds hashes only. The batch parks in the Approvals queue with counts, total value, and the set-aside summary.
- Stream and report. On approval the batch streams with per-event acceptance read back from LinkedIn. The final report says exactly what landed: submitted, accepted, rejected with sample reasons.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
Your deal history converted into an accepted LinkedIn conversion backfill: validated rows streamed with values after your approval, an honest set-aside list for what the API would refuse, and the acceptance report per event batch. The optimizer starts its education with everything you know.
Make it yours
- Backfill in two batches - wins first, then opportunity-stage deals against a second rule - so early and late funnel signals stay distinct.
- After the backfill, switch to the close-the-loop playbook so the history stays current weekly.
- Run the same file through the audience playbook as well: the buyers who already closed are also your best seed for a matched audience.
Frequently asked questions
What does the spreadsheet need to contain?
At minimum an email and a date per row; a value column makes the signal much stronger. Column names barely matter - the mission reads the sheet you have and asks when something is genuinely ambiguous.
Why do some rows get set aside?
LinkedIn's API accepts events from the last 90 days only, and every event needs a parseable timestamp and a valid email to hash. The set-aside list names each excluded row and the reason, so the batch you approve is exactly what will land.
Is a one-time backfill even worth it?
It is the single highest-leverage batch you will ever send: the jump from no outcome signal to real history changes what the algorithm can learn from. The weekly loop afterward keeps it compounding, and this mission hands off to it directly.