Send better conversion signals back to Meta and Google
Choose meaningful outcomes, test the route and activate production delivery without confusing connection with consent to send.
What conversion feedback is
Conversion feedback sends a business outcome from Sissel to an ad platform. Instead of stopping at a page view or form submission, you can report that a lead became qualified or a sale completed. The platform can use the event for reporting and, when you configure it there, campaign optimization.
Choose the outcome deliberately
- Business meaning
The event should represent a result the company actually values.
- Stable definition
Sales and marketing should agree on the CRM rule that creates it.
- Enough volume
An extremely rare event may be useful for reporting but too sparse for day-to-day optimization.
- Reasonable delay
Long sales cycles can make the signal less useful for rapid campaign decisions.
- Dependable identity
The event needs the identifiers and consent required for the selected destination.
Qualified lead is often a useful first candidate for lead-generation teams: it is closer to business value than a raw form submission but usually arrives more often and sooner than a won deal. Your own funnel may justify a different choice.
Reading and sending are separate controls
Connecting Meta or Google can bring campaign hierarchy and spend into reporting while every CRM outcome remains set to Not sent. Each outcome has its own mapping and delivery mode. Nothing becomes a live production conversion simply because the account is connected.
| State | What happens |
|---|---|
| Not sent | The outcome remains visible in Sissel and no production event is delivered to that destination. |
| Test or validation | Use the provider-appropriate test path. Meta test events are explicit; Google outcomes can remain in Test mode. |
| Live | Selected outcomes are eligible for production delivery after the live-readiness checks and confirmation. |
Before enabling live delivery
- 1Verify the source outcome
Confirm type, event time, identity, value and revision behavior in Sissel.
- 2Verify the destination route
Check the selected account, dataset or conversion action for every site that can create the outcome.
- 3Run the provider test
Use the explicit test or validation path and confirm the provider accepts the intended payload.
- 4Reconcile a named window
Compare Sissel with the previous source using the same outcome, dates and documented exclusions.
- 5Review consent and identifiers
Unknown consent is not treated as granted, and missing identifiers remain a visible suppression.
- 6Confirm live activation
Review the exact outcomes that will change from off or test to production delivery.
What to monitor afterward
- Accepted and rejected attempts
Check whether the destination accepted the payload and read the provider response for failures.
- Suppression reasons
Separate destination off, missing consent, missing identifiers and events that are too old.
- Match and reporting lag
Provider interfaces may not display accepted events immediately or attribute every accepted event.
- Duplicate protection
Retries keep a stable delivery identity; investigate source revisions rather than repeatedly resending by hand.
- Business effect
Compare qualified pipeline or sales over an appropriate period, not only the platform’s reported conversion count.
If something is wrong, return the affected outcomes to Not sent while preserving the journey and delivery evidence. Fix the mapping or route, test again, and only then restore live delivery.