What data Scowtt needs

Scowtt predicts how likely each lead is to convert, and what it's worth, from the moment it arrives. It then sends that value back to your ad platforms so they bid toward the leads that actually close. The prediction is only as good as the history it learns from, so every integration needs the same two things: event-level CRM history covering the full lead lifecycle, and event-level web analytics covering what people do before they become a lead.

The two sources

CRM data carries most of the predictive weight. Web analytics sharpens the model by linking on-site behavior to the CRM record, but it doesn't replace CRM history. A CRM-only setup still works, so don't let a slow analytics export hold up your CRM data.

The model learns from activity, not demographics. Showing up to an appointment is an outcome; what predicts it is the detail around it, such as how far ahead the appointment was booked, how many contact attempts came before it, and how quickly the lead responded.

CRM data

Share record-level data, one row per event, each with its own timestamp. The field-by-field list is in Required fields and lifecycle stages. What helps most:

• Send every related record, not a yes/no flag. Six quotes tied to one lead, not "has quote = yes"; three appointments, not "appointment = true". The count, spacing and order all carry signal.
• Include the details around an event, not just the event. When an appointment was booked versus when it's scheduled, which location was chosen, how many contact attempts came before it.
• Include how the lead responded. Whether they accepted, declined or ignored a meeting invite, and any contact they started themselves by email, phone or text.
• Include what was entered on the form. Whatever the lead typed when they submitted: company website, job role, number of locations, product interest.
• Include details your CRM already holds. Existing-customer status, account tenure, size, and geography such as distance from the lead to the location they chose.
• Share more fields, not fewer. The model works out what's predictive; a field held back can't be tested. Exporting your schema headers for a first look is usually quicker than going field by field.

If your warehouse, not your CRM, is the real system of record, the CRM connector alone may miss some data, and a second feed from the warehouse may be needed. If you run several brands, tell your Scowtt team early whether they share one CRM or use separate ones.

Web analytics

Share raw, event-level data tied to a user or session ID, with no aggregation and no personal information.

• If your analytics data already lands in your warehouse, share it from there rather than setting up a second export.
• "We have GA4" often means reporting access. Check whether the event-level export exists and how far back it goes. Exports aren't retroactive, so history starts on the day you turn one on.
• Analytics tools alone don't meet the requirement. GA4, Adobe and Amplitude are web analytics; none of them replaces CRM lifecycle data.

Linking leads to ad clicks

To send a lead's value back to the platform that produced it, Scowtt has to trace the lead to the ad click. There are three ways, in order of preference:

• Either of the first two is enough. They solve the same problem from opposite ends, so choose whichever is easier for your setup. See Capturing click IDs on your forms.
• Start capturing before the integration is live. Neither method fills in the past. A change made at kickoff has weeks of coverage by the time campaigns launch.
• This doesn't hold up modeling. Models train on CRM activity and don't depend on the link. The link matters for sending values back and for checking campaign results, and both can happen in parallel.
• Some leads will never have a click. In businesses with phone, walk-in or in-store leads, up to half can be offline. They still train the model; they just can't be matched to a click.
• Relying only on enhanced conversions works, but blind. It depends entirely on the platform's own matching, so neither you nor Scowtt can check how well campaigns are being credited.

History and freshness

Freshness matters because of the feedback loop, not the training. Scowtt sends values back to your ad platforms several times a day. If a lead's first outcome reaches Scowtt a day late, the platform has already spent another day finding leads like it before Scowtt can say whether it was any good.

• Treat the first load and the ongoing feed separately. The history is a one-time bulk export, usually too large for an API; the ongoing feed is small and can use whatever method you prefer.
• Tell Scowtt your worst-case delay, not just your schedule. "We run every six hours" and "we're six hours behind" are different. What matters is the longest gap between something happening and Scowtt seeing it.
• A steady delay is fine. A consistent few-hour lag works; what hurts is an unpredictable delay, or updates only once a day or less.
• If your warehouse updates slowly, ask whether the data can come from further upstream, such as the application database, which often removes the delay entirely.
• Shorter sales cycles need fresher data. A business where leads convert within days benefits most from frequent updates.

For how to send your data, see Choose how to connect your data and Data format standards. You can mix methods: for example, a bulk export for the history and a bucket or API for ongoing updates.

Your conversion definition and value

Every integration needs one clear statement of what counts as a conversion, because that's what the model learns to predict and what your ad platforms end up bidding toward.

• Choose the real outcome, not a stand-in. A completed, paid installation, not a booked appointment. Optimizing to a stand-in teaches the platform to find people who book and never buy.
• Give non-sales outcomes a value. Ad platforms only understand currency. A donation, application or signup can get a dollar figure based on what it's worth to you; it doesn't have to be revenue.
• Use lifetime value when repeat business is the point.
• If several actions create a lead and some are worth far more, agree that order of value before modeling starts.
• Expect new conversion actions in your ad account. Scowtt creates its own conversion actions alongside your existing ones, so your current reporting isn't affected.

Personal data

Modeling runs on activity, not identity. Name, email and phone add nothing to the prediction. The only reason to share email or phone is to improve match rates with enhanced conversions, and hashed values are enough for that.

• You can hash on your side. Add hashed email and phone columns to your own tables, so the raw values never leave your environment. Agree the hashing method with your Scowtt team before the first transfer; see Data format standards.
• Mark opt-outs with a flag rather than removing records. A suppression field lets you see what was excluded, and lets Scowtt leave those records out of both modeling and uploads. Records dropped before sharing can't be checked later by either side.
• Postal code or distance is usually enough location detail, and sharing less than a full address avoids a privacy review.

For how Scowtt keeps each customer's data separate, see How Scowtt handles your data and No PII required.

What isn't required

One thing that doesn't work as a source: a feed built only to send conversions to ad platforms, such as an existing offline-conversion upload. Those feeds are shaped for delivery, not modeling, so Scowtt needs the system that produced them.