From ad click to qualified lead: How Sissel works

Sissel brings website visits, customer outcomes and ad-platform data into one explainable chain. Each stage remains separate: observing a visit is not the same as identifying a person, crediting a campaign is not the same as proving causality, and connecting an ad account is not the same as sending conversions.

1. 1
   Record the visit

   Keep the landing page, referrer, campaign parameters and supported ad click identifiers when collection is allowed.

2. 2
   Link the visitor

   Connect the browser journey to a known person using explicit identity evidence.

3. 3
   Receive the outcome

   Bring in a lead, stage change, sale or value from a CRM connector, Zapier or the public API.

4. 4
   Apply the attribution rule

   Evaluate eligible touchpoints inside the configured lookback and store the credited result with its model.

5. 5
   Show the evidence

   Make the visit, identity link, outcome, credit decision and exclusions inspectable as a chronological journey.

6. 6
   Send only what you choose

   Route selected outcomes to an ad platform after testing and an explicit live activation.

A source-bearing visit can include UTMs, referrer information, the landing page and supported advertising click identifiers. The consent state travels with the event so collection and later delivery can be evaluated separately. If your site requires consent and it has not been granted, Sissel does not quietly turn that unknown state into permission.

Attribution needs a trustworthy bridge between a browser journey and the later CRM result. That bridge can be a signed tracking token, normalized email or phone, a source-scoped external ID, or an explicit server-to-server identity call. The source of the link is retained so it can be inspected later.

If the CRM outcome has no usable identity, Sissel can retain the outcome but cannot invent the website journey that belongs to it. That distinction prevents a CRM record from being presented as campaign evidence when no link exists.

The workspace defines an attribution model and a lookback window. For every outcome, Sissel checks the known person’s touchpoints before the outcome, removes those outside the window, and applies the selected model. The stored result includes the model, lookback and reason, making the decision reproducible rather than a hidden score.

Ad connections can import account structure and spend while every outcome remains set to Not sent. When you choose an outcome for delivery, Sissel checks the route, consent, required identifiers and platform age limits. Attempts, failures, suppressions and retries remain visible.

A stable delivery identity prevents an ordinary retry from quietly creating a duplicate result. Enabling live delivery requires a separate review, so reading data from an account never becomes production activation by accident.