Before you install Sissel: A simple setup checklist
Choose a manageable first journey, gather the right access and agree on the outcome you want to measure.
Choose a small first scope
A good first setup proves one complete journey. Pick one production website, one source of customer outcomes and one ad account. Add more only after you can inspect a real visit, identity link and outcome together.
- Website
The production domain that receives the paid traffic you want to evaluate.
- Outcome source
The CRM, server integration or Zapier workflow that records the later business result.
- Primary outcome
One consistently defined result such as qualified lead, won deal or sale.
- Ad account
The Meta or Google account used for the campaigns sending traffic to that site.
Know who can provide access
| Responsibility | What you need from them |
|---|---|
| Marketing | Campaign naming, ad-account access and the outcome the team wants to optimize for |
| Website owner | Permission to install the SDK, configure allowed origins and run a production test |
| Consent owner | The current consent mode, purposes and the event that represents a granted choice |
| CRM owner | API or connector access plus the fields and stages that define each outcome |
| Sales or revenue owner | A written definition of qualified, won, value and currency |
Website and consent checklist
- Production domain
Use the exact domain that will send events, including any separate landing-page domain.
- Installation route
Decide whether the SDK will be installed directly, through your application or through a tag manager.
- Consent behavior
Confirm whether collection requires an explicit grant and which consent-management event Sissel should receive.
- Lead capture path
List the forms or server flows that create the lead and how they can carry a signed token or known identifier.
- Campaign parameters
Check that final URLs retain supported click identifiers and the campaign parameters your team relies on.
- Test journey
Choose a form and CRM stage that can be exercised without confusing real sales reporting.
Outcome and CRM checklist
For each outcome, identify the source event, stable record ID, event time, person identity and any value or currency. Decide how updates and cancellations are represented. A label such as “qualified” is not enough unless everyone agrees on the CRM condition that creates it.
What “ready” looks like
- Collection is visible
A consented test visit appears with the expected landing page and campaign evidence.
- Identity is visible
The form or server flow links the test visitor to the expected person.
- The outcome is visible
The chosen CRM event arrives once with the correct type, time and value.
- Credit is explainable
The journey shows why a source received credit—or clearly states why none did.
- Delivery remains controlled
All destinations stay off until a named reconciliation and live review are complete.
You do not need to replace your existing analytics, import perfect history or map every CRM stage before starting. One verified production journey is a stronger foundation than a broad setup nobody has inspected.