LeadBoxer Platform For Developers: Event Ingestion, Identity Stitching And Scoring

If your event data does not connect to the right person and account, your scores are off from the start. I’d boil this platform down to four jobs: send events in, match them to people and companies, score intent, and push those scores into tools your team already uses.

Here’s the article in plain English:

• I track website events with a JavaScript snippet and product/backend events with the Track API.

• I connect anonymous visits to known users with IDs like email, userId, and CRM IDs.

• I score actions by intent, such as +10 for pricing-page revisits, +40 for demo requests, and decay older activity over time.

• I roll person activity up to the account level to spot buying-group interest.

• I send score changes to the CRM, Slack, internal dashboards, and in-app flows.

A few details stand out right away. The API accepts GET and POST requests at https://log.leadboxer.com. Each event needs at least si and ti. Account intent can be flagged when 3+ contacts from the same company hit pricing pages in 14 days. And teams using signal-based scoring in this piece reported 47% higher conversion rates, 43% larger average deal sizes, and 38% more closed deals per quarter than static scoring.

So if I were setting this up, I’d keep the order simple: ingest first, resolve second, score third, activate last. That is the whole system, stripped down to what matters.

LeadBoxer Signal Pipeline: Ingest, Resolve, Score & Activate

Event Ingestion Setup

LeadBoxer collects behavior data through two paths that work side by side:

• a client-side JavaScript tracking script for website activity

• a server-side Track API for product and backend events

Together, these make up the input layer for identity stitching and scoring. Put simply, they send the raw signals both stages need.

Tracking Script for Website Behavior

Add the JavaScript snippet to your global layout or tag manager to track page views, referrers, UTM parameters, device details, and session activity. Each page view sends the URL, page title, referrer, and browser metadata.

For high-intent pages, don’t stop at automatic page views. If someone lands on /pricing, send a custom event like Viewed Pricing Page with properties such as plan_category and currency. For forms, send Demo Form Started and Demo Form Submitted with fields like company_size and use_case.

That extra detail matters. It gives scoring enough context to tell the difference between casual browsing and actual buying intent.

The script also tracks anonymous behavior before a user logs in or fills out a form. It assigns a client-side identifier, which can later connect to a known email or user ID during identity resolution. That early context matters more than it may seem at first. Multiple pricing-page visits in one session, or return visits from a certain campaign within 48 hours, are hard to piece together from backend logs alone.

Anonymous browser activity only starts to pay off once it can be tied to a person or account.

Use the script for anonymous browser behavior. Use the Track API for authenticated events and revenue events.

API Ingestion for Product and Backend Events

The LeadBoxer Track API accepts both GET and POST requests at https://log.leadboxer.com, using URL-encoded payloads. Server-side ingestion gets around ad blockers, browser privacy limits, and disabled JavaScript.

Use the API for events tied to authenticated actions and revenue signals, such as User Logged In, Trial Upgraded, Plan Changed, and Subscription Cancelled. For a trial upgrade, your billing service might send a payload with uid, account_id, new_plan, and mrr_usd like 299.00. For repeat logins, include login_count and plan_tier with the authentication event so scoring rules can weigh engagement frequency.

Include proxy=true on server-side events to preserve client geolocation and user-agent data.

To connect browser events with backend events, use the ot_uid() JavaScript function to get the LeadBoxer-generated user ID from the browser, then pass that value into your backend calls. That step ties anonymous website sessions and authenticated product events to the same profile, which then feeds unified identity records downstream.

Once both sources are live, standardize event names and fields before scoring starts using them.

Event Schema and Validation Rules

Every event needs at least two fields: si (your dataset ID) and ti (the event name). Everything else is optional, but still useful.

For naming, stick with a consistent Verb Object pattern, such as Viewed Pricing Page, Submitted Demo Request, and Upgraded Subscription. Property names should also stay consistent. For example, use ASCII field names like plan_tier across event types. The same goes for account fields: pick one name and keep it. If you mix account_id and company_id, stitching and scoring rules can break.

Validate events in a test dataset. Check names, UTC timestamps, and identifiers, and reject payloads that are missing required fields. Any custom property attached to an event also flows up to the parent session and user profile, so clean schema rules are what keep stitching and scoring dependable.

With clean ingestion in place, identity stitching can merge sessions, devices, and CRM records into one profile.

Identity Stitching Across Users, Accounts, and Systems

Clean event ingestion only works if you can tie the same visitor together across sessions, devices, and tools. That usually starts with stable identifiers like email, userId, or CRM contact IDs.

Anonymous to Known User Resolution

Every new visitor starts out anonymous. LeadBoxer assigns an anonymous visitor ID in a first-party cookie and stores behavioral events under that temporary profile.

Once a durable identifier shows up - like an email from a form submission, a userId from a login event, or a CRM contact ID sent through the Track API - LeadBoxer merges those earlier anonymous sessions into the known profile, with timestamps preserved. That means the person’s history stays connected instead of getting split into separate records.

Backend-sent identifiers tend to be the steadiest signals because browser limits don’t affect them the same way.

Cross-Session, Cross-Device, and CRM Matching

Cookies don’t carry over across devices or browsers. So if someone starts on mobile and later comes back on desktop, a stable userId or email is what ties both sessions to the same person record.

CRM integration adds another matching layer. When a contact’s email or CRM contact ID enters the event stream, LeadBoxer maps that person to a company record and links them to a shared account profile with other contacts from the same organization. It sounds simple, but it matters a lot. If company domains aren’t normalized before matching, you can end up with duplicate account records and split histories.

For server-side events that update a profile, include proxy=true. That keeps the server’s IP and user-agent from replacing the visitor’s original location and browser data.

Those unified person and account records become the inputs for scoring rules in the next section.

Person-Level and Account-Level Views

Person-level profiles are best for lead routing and alerts. Account-level rollups are better for spotting buying-group activity. Same data, different use cases.

Here’s the difference:

• A single contact who submits a demo form after visiting the pricing page should trigger fast follow-up based on that person’s score.

• An account where one contact requests a demo, another visits the pricing page, and a third downloads an integration guide shows buying-group intent that wouldn’t show up in any one person’s score alone.

LeadBoxer’s IP-to-company matching can surface account-level intent even when individual visitors remain anonymous. Those unified profiles then feed lead and account scoring.

Scoring Models for Lead and Account Signals

Once profiles are unified, LeadBoxer can score both contact- and account-level signals based on behavior, firmographic fit, and high-intent events. Those scores update as new events come in. For developers, there are four controls that shape the model: event type, weight, threshold, and refresh logic.

Behavioral Scoring Inputs

A simple way to start is to group events into three intent bands: low intent, engaged, and high intent.

Keep low-intent actions in the 1–5 range. Put engaged behaviors around 5–15. Set high-intent events at 25+, and save 40–60 for actions like demo requests and trial signups.

Here’s what that can look like in practice:

• Pricing-page revisits: +10

• Key feature use: +15

• Demo requests: +40

That kind of spread helps teams tell the difference between someone who’s browsing and someone who may be ready to talk by identifying your website visitors.

Weighted Rules, Thresholds, and Score Refresh Logic

Point values alone don’t tell the whole story. You also need weights so passive activity doesn’t look the same as buying intent.

Assign a weight to each event type, then multiply the event’s base score by that weight to get the final score. For example: demo request 1.0, pricing revisit 0.7, email open 0.1.

Cap generic page views at 10 points per day so casual browsing doesn’t inflate scores.

Threshold bands also give marketing, sales, and ops teams a shared way to talk about qualification:

Then there’s score decay. Without it, old activity can sit there forever and make cold leads look warm. A common setup is to multiply the behavior score by 0.9 for each week of inactivity, with a floor of zero.

Recency weighting works alongside decay by giving more weight to events from the past 7–14 days and less to older activity. That keeps the ranking tied to current intent, not something that happened a month ago.

Account-Level Intent and Buying Group Signals

Contact scores help, but account scores show whether intent is building across a buying group. LeadBoxer rolls contact scores into an account score using the company domain or CRM account ID.

Teams can aggregate those scores in a few ways. They might sum active contacts, weight by seniority, or require a minimum number of high-intent contacts from the same account.

One practical rule is to set account_intent_status: "High" when three or more unique contacts from the same domain view pricing pages within a 14-day window, or when at least one demo request appears alongside multiple feature-usage events from different users.

LeadBoxer can also mark an account as SQL when both behavior_score ≥ 60 and fit_score ≥ 20 are met.

Activation and Workflow Output

Once your scores are on the same scale, the next step is simple: send them where teams will use them. That usually means CRM fields first, then alerts, dashboards, and the product UI. CRM sync is the default destination. Alerts and product workflows are the fast lane for high-intent activity.

CRM, Automation, and Internal App Triggers

Use LeadBoxer as the source for behavior signals, and keep your CRM as the system of record for sales activity. Map LeadBoxer person and account IDs to CRM Lead, Contact, and Account objects with custom fields such as Lead Score, Account Intent Score, Last High-Intent Event, Last Activity Timestamp, and a main identifier like email or domain.

Then upsert records by email or domain. Push high-intent updates in near real time, and batch routine score refreshes every 5–15 minutes. That gives sales teams timely context without flooding the CRM.

For alerts, notify people only when a score crosses a threshold, not on every single update. For example:

• Send a Slack alert when a lead score hits 80 and the contact has a Director or VP title

• Send an alert when an account intent score climbs by 20 or more points within 24 hours

Each alert should include the person, the trigger, the top behaviors, and the timestamp. Add a 7-day cooldown per person or account so teams don't get the same alert again and again.

Those same scores can also power in-product actions.

Embedded Product Workflows

SaaS teams can show LeadBoxer person and account scores right inside their own product in three common ways. A product-qualified lead (PQL) dashboard can rank users and accounts by score, with filters such as High intent this week. Intent badges can show labels like High Intent, Evaluating, or Dormant at the row level in admin panels or account overview screens. And upsell prompts can show an in-app banner when an account score crosses a threshold and multiple users have used premium features.

To keep the UI fast, fetch and cache scores through a backend service.

Conclusion: Build a Reliable Signal Pipeline

In practice, LeadBoxer turns ingest, resolve, score, and activate into one signal pipeline. Signal-qualified leads can improve conversion, deal size, and closed deals - organizations using this approach see 47% better conversion rates, 43% larger average deal sizes, and 38% more closed deals per quarter compared with static lead scoring.

FAQs

How do I connect anonymous visits to known users?

LeadBoxer connects anonymous visits to known users by merging sessions after it captures a stable identifier.

This usually happens when your setup sends identifiers like an email address or internal user ID during form submissions, newsletter link clicks, or login events. With the Track API, LeadBoxer can connect earlier anonymous activity to the right user profile.

Which events should I send from JavaScript vs. the API?

Use the JavaScript SDK for client-side events that happen in an active browser session. That includes SPA route changes, outbound clicks, file downloads, and pricing-page visits. It also manages sessions and can attach user properties.

Use the Track API for server-side events that happen outside the browser. That includes backend processes, database updates, subscription upgrades, invoice payments, and CRM status changes. It’s also the better choice when you need more reliable tracking that won’t be blocked by browser limits or ad blockers.

How should I set lead and account scoring thresholds?

Focus on high-value behavior signals like pricing page visits, demo requests, and repeat logins. Those actions usually say a lot more than a casual page view. To keep scoring steady, use identity stitching to connect anonymous visits with known user activity, then record those milestones as events with the Track API.

In the LeadBoxer platform, set up scoring to weigh engagement, ICP fit, and persona match. From there, check your thresholds on a regular basis and tune them as more activity data comes in, so the signals stay clean and useful.

Related Blog Posts

• Lead intelligence as an API

• LeadBoxer Platform for Website Visitor Identification and IP-to-Company Matching

• LeadBoxer Platform: API-First Company Identification For Website And Product Traffic

• Replacing Homegrown Tracking Pipelines With The LeadBoxer Platform