This is a synthetic dataset for practicing B2B lead scoring. It was generated by\nleadforge, an open-source Python framework\nfor producing realistic CRM/funnel training data. No real company, customer, or\ntransaction is represented.
\nWhat you are predicting: Each row is a sales lead at a fictional B2B SaaS company.\nThe task is binary classification:
\n\n\n\n
converted_within_90_days— did this lead close as a paid deal within 90 days?
Features capture the first 30 days of CRM activity per lead (email/call touches, product\nsessions, deal stage, account firmographics). The label is derived from simulated events —\nnever directly sampled — so there is genuine causal structure behind the signal.
\n| Property | \nValue | \n
|---|---|
| Conversion rate | \n~43% | \n
| Signal strength | \n0.90 / 1.0 (high) | \n
| Noise level | \n0.10 / 1.0 (low) | \n
| Missing values | \n~2% | \n
| LR AUC (test, 5-seed median) | \n0.671 | \n
| GBM AUC (test, 5-seed median) | \n0.684 | \n
| Average precision (LR) | \n0.555 | \n
| Precision @100 | \n0.60 | \n
The intro tier is the easiest version of this task. Signal is strong, conversion rate\nis high (~43% of leads convert), and missing values are minimal. A simple logistic\nregression is competitive. Use this tier to prototype your pipeline and sanity-check your\napproach before scaling up difficulty.
\nThis dataset ships in three tiers — intro → intermediate → advanced — with decreasing\nsignal, lower conversion rates, and heavier noise and missingness. All three tiers share\nthe same schema and simulate the same fictional B2B world.
\n| Table | \nRows | \nDescription | \n
|---|---|---|
| accounts | \n1,500 | \nOne row per company | \n
| contacts | \n4,200 | \nOne row per buyer-side individual (multiple per account) | \n
| leads | \n5,000 | \nOne row per lead — the prediction unit | \n
| touches | \n38,561 | \nMarketing / SDR outreach events (first 30 days per lead) | \n
| sessions | \n10,171 | \nProduct demo or trial sessions (first 30 days per lead) | \n
| sales_activities | \n21,358 | \nCRM activities: calls, emails, meetings (first 30 days per lead) | \n
| opportunities | \n4,426 | \nDeal records opened before the 30-day snapshot | \n
Snapshot-safe: event tables contain only rows with timestamps ≤ 30 days from lead\ncreation. Outcome columns (converted_within_90_days, conversion_timestamp,\nclose_outcome) are excluded from the public relational tables — they appear only in the\ntask splits.
| Category | \nColumns | \nExamples | \n
|---|---|---|
| Account | \n6 | \naccount_id, industry, region | \n
| Contact | \n4 | \ncontact_id, role_function, seniority | \n
| Lead metadata | \n3 | \nlead_id, lead_created_at, lead_source | \n
| Engagement | \n11 | \ntouch_count, inbound_touch_count, outbound_touch_count | \n
| Sales | \n6 | \nactivity_count, days_since_last_touch, opportunity_created | \n
| Target | \n1 | \nconverted_within_90_days | \n
⚠ Intentional leakage trap: total_touches_all aggregates touches over the full\n90-day window (not just the 30-day feature window) and is deliberately retained as a\nleakage-detection teaching exercise. It is flagged leakage_risk=True in\nfeature_dictionary.csv. Drop it from your feature set unless you are studying leakage.
See feature_dictionary.csv for the full column-by-column specification.
The dataset simulates a fictional company — Veridian Technologies — a Series B\nstartup (Austin, TX, founded 2017) selling Veridian Procure, a cloud\nprocurement / AP automation SaaS. Everything below is invented:
\nIn this public version, the hidden causal graph, latent trait scores, and mechanism\nparameters are withheld. The instructor companion bundle includes them.
\nimport pandas as pd\n\n# Flat CSV — all leads, all splits combined (convenient for exploration)\ndf = pd.read_csv("lead_scoring.csv")\nX = df.drop(columns=["converted_within_90_days"])\ny = df["converted_within_90_days"]\n\n# Parquet task splits — recommended for model training\ntrain = pd.read_parquet("tasks/converted_within_90_days/train.parquet")\nvalid = pd.read_parquet("tasks/converted_within_90_days/valid.parquet")\ntest = pd.read_parquet("tasks/converted_within_90_days/test.parquet")\n\n# Relational tables — for feature engineering\nleads = pd.read_parquet("tables/leads.parquet")\ntouches = pd.read_parquet("tables/touches.parquet")\nSplits are 70 / 15 / 15 (train / valid / test), stratified on the target, deterministic\ngiven seed 42.
\nNote on account overlap: ~93% of test-set accounts also appear in the training set\n(splits are keyed on lead_id). Headline AUC overstates generalisation to unseen\naccounts. For a faithful out-of-sample estimate, use\nGroupKFold(groups=df["account_id"]).
Generated with leadforge v1.0.0, recipe b2b_saas_procurement_v1, seed 42,\ndifficulty intro. To reproduce:
pip install leadforge\nleadforge generate --recipe b2b_saas_procurement_v1 --seed 42 \\\n --mode student_public --difficulty intro --out my_bundle\nEvery file in this bundle is SHA-256 hashed in manifest.json. Run\nleadforge validate my_bundle to verify integrity.
Author: Shay Palachy Affek · Kaggle · GitHub
\nlead_id; most test accounts\nalso appear in train. Headline metrics overstate generalisation to unseen accounts.total_touches_all is the intentional exception — it aggregates over the\nfull 90-day window and is a leakage trap.This is a synthetic dataset for practicing B2B lead scoring. It was generated by\nleadforge, an open-source Python framework\nfor producing realistic CRM/funnel training data. No real company, customer, or\ntransaction is represented.
\nWhat you are predicting: Each row is a sales lead at a fictional B2B SaaS company.\nThe task is binary classification:
\n\n\n\n
converted_within_90_days— did this lead close as a paid deal within 90 days?
Features capture the first 30 days of CRM activity per lead (email/call touches, product\nsessions, deal stage, account firmographics). The label is derived from simulated events —\nnever directly sampled — so there is genuine causal structure behind the signal.
\n| Property | \nValue | \n
|---|---|
| Conversion rate | \n~22% | \n
| Signal strength | \n0.70 / 1.0 (medium) | \n
| Noise level | \n0.30 / 1.0 (moderate) | \n
| Missing values | \n~8% | \n
| LR AUC (test, 5-seed median) | \n0.662 | \n
| GBM AUC (test, 5-seed median) | \n0.634 | \n
| Average precision (LR) | \n0.332 | \n
| Precision @100 | \n0.33 | \n
The intermediate tier is the default benchmark. Conversion rate is ~22% — more\nrealistic for B2B SaaS than the intro tier — and noise is moderate enough that simple\nfeature engineering starts to matter. GBM does not consistently beat logistic regression\nhere (the snapshot is dominated by near-linear features); that gap is worth investigating.\nCalibration becomes important at this prevalence — a model that predicts the right rank\norder can still be badly miscalibrated.
\nThis dataset ships in three tiers — intro → intermediate → advanced — with decreasing\nsignal, lower conversion rates, and heavier noise and missingness. All three tiers share\nthe same schema and simulate the same fictional B2B world.
\n| Table | \nRows | \nDescription | \n
|---|---|---|
| accounts | \n1,500 | \nOne row per company | \n
| contacts | \n4,200 | \nOne row per buyer-side individual (multiple per account) | \n
| leads | \n5,000 | \nOne row per lead — the prediction unit | \n
| touches | \n38,724 | \nMarketing / SDR outreach events (first 30 days per lead) | \n
| sessions | \n10,012 | \nProduct demo or trial sessions (first 30 days per lead) | \n
| sales_activities | \n20,679 | \nCRM activities: calls, emails, meetings (first 30 days per lead) | \n
| opportunities | \n4,255 | \nDeal records opened before the 30-day snapshot | \n
Snapshot-safe: event tables contain only rows with timestamps ≤ 30 days from lead\ncreation. Outcome columns (converted_within_90_days, conversion_timestamp,\nclose_outcome) are excluded from the public relational tables — they appear only in the\ntask splits.
| Category | \nColumns | \nExamples | \n
|---|---|---|
| Account | \n6 | \naccount_id, industry, region | \n
| Contact | \n4 | \ncontact_id, role_function, seniority | \n
| Lead metadata | \n3 | \nlead_id, lead_created_at, lead_source | \n
| Engagement | \n11 | \ntouch_count, inbound_touch_count, outbound_touch_count | \n
| Sales | \n6 | \nactivity_count, days_since_last_touch, opportunity_created | \n
| Target | \n1 | \nconverted_within_90_days | \n
⚠ Intentional leakage trap: total_touches_all aggregates touches over the full\n90-day window (not just the 30-day feature window) and is deliberately retained as a\nleakage-detection teaching exercise. It is flagged leakage_risk=True in\nfeature_dictionary.csv. Drop it from your feature set unless you are studying leakage.
See feature_dictionary.csv for the full column-by-column specification.
The dataset simulates a fictional company — Veridian Technologies — a Series B\nstartup (Austin, TX, founded 2017) selling Veridian Procure, a cloud\nprocurement / AP automation SaaS. Everything below is invented:
\nIn this public version, the hidden causal graph, latent trait scores, and mechanism\nparameters are withheld. The instructor companion bundle includes them.
\nimport pandas as pd\n\n# Flat CSV — all leads, all splits combined (convenient for exploration)\ndf = pd.read_csv("lead_scoring.csv")\nX = df.drop(columns=["converted_within_90_days"])\ny = df["converted_within_90_days"]\n\n# Parquet task splits — recommended for model training\ntrain = pd.read_parquet("tasks/converted_within_90_days/train.parquet")\nvalid = pd.read_parquet("tasks/converted_within_90_days/valid.parquet")\ntest = pd.read_parquet("tasks/converted_within_90_days/test.parquet")\n\n# Relational tables — for feature engineering\nleads = pd.read_parquet("tables/leads.parquet")\ntouches = pd.read_parquet("tables/touches.parquet")\nSplits are 70 / 15 / 15 (train / valid / test), stratified on the target, deterministic\ngiven seed 42.
\nNote on account overlap: ~93% of test-set accounts also appear in the training set\n(splits are keyed on lead_id). Headline AUC overstates generalisation to unseen\naccounts. For a faithful out-of-sample estimate, use\nGroupKFold(groups=df["account_id"]).
Generated with leadforge v1.0.0, recipe b2b_saas_procurement_v1, seed 42,\ndifficulty intermediate. To reproduce:
pip install leadforge\nleadforge generate --recipe b2b_saas_procurement_v1 --seed 42 \\\n --mode student_public --difficulty intermediate --out my_bundle\nEvery file in this bundle is SHA-256 hashed in manifest.json. Run\nleadforge validate my_bundle to verify integrity.
Author: Shay Palachy Affek · Kaggle · GitHub
\nlead_id; most test accounts\nalso appear in train. Headline metrics overstate generalisation to unseen accounts.total_touches_all is the intentional exception — it aggregates over the\nfull 90-day window and is a leakage trap.This is a synthetic dataset for practicing B2B lead scoring. It was generated by\nleadforge, an open-source Python framework\nfor producing realistic CRM/funnel training data. No real company, customer, or\ntransaction is represented.
\nWhat you are predicting: Each row is a sales lead at a fictional B2B SaaS company.\nThe task is binary classification:
\n\n\n\n
converted_within_90_days— did this lead close as a paid deal within 90 days?
Features capture the first 30 days of CRM activity per lead (email/call touches, product\nsessions, deal stage, account firmographics). The label is derived from simulated events —\nnever directly sampled — so there is genuine causal structure behind the signal.
\n| Property | \nValue | \n
|---|---|
| Conversion rate | \n~8% | \n
| Signal strength | \n0.50 / 1.0 (moderate) | \n
| Noise level | \n0.55 / 1.0 (high) | \n
| Missing values | \n~18% | \n
| LR AUC (test, 5-seed median) | \n0.624 | \n
| GBM AUC (test, 5-seed median) | \n0.600 | \n
| Average precision (LR) | \n0.122 | \n
| Precision @100 | \n0.11 | \n
The advanced tier is a calibration and rare-event exercise. Conversion rate is ~8% —\na realistic low-prevalence regime for mid-market SaaS — and noise is heavy enough that\ncount features show artifact zeros (Gaussian noise clamped to zero; treat zero clusters as\ndata-cleaning material, not reliable signal). AUC barely moves across tiers by design;\nhere you'll want average precision, P@K, and value-weighted ranking\n(expected_acv × P(convert)) to measure what matters. Calibration is harder in this\ntier: a miscalibrated model can rank correctly but still predict systematically wrong\nprobabilities — the kind of mistake that breaks real-world decision thresholds.
This dataset ships in three tiers — intro → intermediate → advanced — with decreasing\nsignal, lower conversion rates, and heavier noise and missingness. All three tiers share\nthe same schema and simulate the same fictional B2B world.
\n| Table | \nRows | \nDescription | \n
|---|---|---|
| accounts | \n1,500 | \nOne row per company | \n
| contacts | \n4,200 | \nOne row per buyer-side individual (multiple per account) | \n
| leads | \n5,000 | \nOne row per lead — the prediction unit | \n
| touches | \n38,208 | \nMarketing / SDR outreach events (first 30 days per lead) | \n
| sessions | \n9,942 | \nProduct demo or trial sessions (first 30 days per lead) | \n
| sales_activities | \n19,995 | \nCRM activities: calls, emails, meetings (first 30 days per lead) | \n
| opportunities | \n4,004 | \nDeal records opened before the 30-day snapshot | \n
Snapshot-safe: event tables contain only rows with timestamps ≤ 30 days from lead\ncreation. Outcome columns (converted_within_90_days, conversion_timestamp,\nclose_outcome) are excluded from the public relational tables — they appear only in the\ntask splits.
| Category | \nColumns | \nExamples | \n
|---|---|---|
| Account | \n6 | \naccount_id, industry, region | \n
| Contact | \n4 | \ncontact_id, role_function, seniority | \n
| Lead metadata | \n3 | \nlead_id, lead_created_at, lead_source | \n
| Engagement | \n11 | \ntouch_count, inbound_touch_count, outbound_touch_count | \n
| Sales | \n6 | \nactivity_count, days_since_last_touch, opportunity_created | \n
| Target | \n1 | \nconverted_within_90_days | \n
⚠ Intentional leakage trap: total_touches_all aggregates touches over the full\n90-day window (not just the 30-day feature window) and is deliberately retained as a\nleakage-detection teaching exercise. It is flagged leakage_risk=True in\nfeature_dictionary.csv. Drop it from your feature set unless you are studying leakage.
See feature_dictionary.csv for the full column-by-column specification.
The dataset simulates a fictional company — Veridian Technologies — a Series B\nstartup (Austin, TX, founded 2017) selling Veridian Procure, a cloud\nprocurement / AP automation SaaS. Everything below is invented:
\nIn this public version, the hidden causal graph, latent trait scores, and mechanism\nparameters are withheld. The instructor companion bundle includes them.
\nimport pandas as pd\n\n# Flat CSV — all leads, all splits combined (convenient for exploration)\ndf = pd.read_csv("lead_scoring.csv")\nX = df.drop(columns=["converted_within_90_days"])\ny = df["converted_within_90_days"]\n\n# Parquet task splits — recommended for model training\ntrain = pd.read_parquet("tasks/converted_within_90_days/train.parquet")\nvalid = pd.read_parquet("tasks/converted_within_90_days/valid.parquet")\ntest = pd.read_parquet("tasks/converted_within_90_days/test.parquet")\n\n# Relational tables — for feature engineering\nleads = pd.read_parquet("tables/leads.parquet")\ntouches = pd.read_parquet("tables/touches.parquet")\nSplits are 70 / 15 / 15 (train / valid / test), stratified on the target, deterministic\ngiven seed 42.
\nNote on account overlap: ~93% of test-set accounts also appear in the training set\n(splits are keyed on lead_id). Headline AUC overstates generalisation to unseen\naccounts. For a faithful out-of-sample estimate, use\nGroupKFold(groups=df["account_id"]).
Generated with leadforge v1.0.0, recipe b2b_saas_procurement_v1, seed 42,\ndifficulty advanced. To reproduce:
pip install leadforge\nleadforge generate --recipe b2b_saas_procurement_v1 --seed 42 \\\n --mode student_public --difficulty advanced --out my_bundle\nEvery file in this bundle is SHA-256 hashed in manifest.json. Run\nleadforge validate my_bundle to verify integrity.
Author: Shay Palachy Affek · Kaggle · GitHub
\ndays_since_last_touch = 0) may be noise artifacts rather than genuine\nzero values — treat them as intentional data-cleaning material.lead_id; most test accounts\nalso appear in train. Headline metrics overstate generalisation to unseen accounts.total_touches_all is the intentional exception — it aggregates over the\nfull 90-day window and is a leakage trap.