Customer Marketing Response

Customer Marketing Response Skill

This skill documents production-grade, leakage-safe feature engineering for customer marketing response models — with explicit coverage for banking and credit-card contexts (email, physical mail, portal/app presentments, in-branch/CRM signals, and application events). The canonical row is (customer_id, cutoff_date) and all features must be computable from data with timestamps <= cutoff_date.

Scope & targets

• Typical targets: responded_to_offer (click, apply-start, application-submit), applied (application started/submitted), approved (decision), and short-term engagement signals (clicks, opens). Define your target precisely and the label window (e.g., 15/30/90 days).
• Prediction cadence: daily/weekly/monthly snapshots. For marketing response, campaign/queue-level holdout or A/B splits are preferred for causal evaluation.

Key principles

• Time-truncate at row-level: filter event tables by timestamp <= cutoff_date before aggregating.
• Avoid application-outcome leakage: do not include features generated by the approval flow or post-apply placements unless timestamped before the cutoff.
• Use short windows (15/30 days) for digital presentments and longer windows (90–365 days) for mail/email histories.

Canonical tables (confirm mapping to your warehouse)

• customers: customer_id, demographics, signup_date, acquisition_channel, kyc_level
• campaigns: campaign_id, campaign_name, type (Prospect/Customer), channel (mail, physical), sent_date
• marketing_events / presentments: presentment_id, customer_id (nullable), session_id, placement, placement_type, product_shown, campaign_id, click_flag, event_ts
• email_events: message_id, customer_id, event_type (delivered, open, click), timestamp
• portal_events / app_events: impression_id, customer_id, placement, event_type, timestamp, session_id
• applications: application_id, customer_id, product, event_type (start, submit, approved), timestamp
• transactions / banking spend (optional for credit-card models): txn_id, customer_id, amount, merchant_category, txn_ts
• branch_visits / crm_interactions: visit_id, customer_id, visit_date, channel, purpose, sentiment

Windows guidance

• Digital presentments and portal/app activity: compute features over 15d and 30d windows (short-term signals). Optionally include 7d for very short campaigns.
• Email and physical mail exposures: consider up to 365d history for recency and frequency features.
• Application-label windows: define label horizon (e.g., 30 days post-exposure) and ensure features use only pre-cutoff data.

Feature families (exhaustive checklist)

Implement these families as separate, testable functions and validate leakage after each family.

1. Exposure & presentment features

• presentments_{7,15,30}d_count, presentment_clicks_{7,15,30}d
• card_presentments_{7,15,30}d, card_clicks_{7,15,30}d
• presentments_per_session_median, sessions_with_card_presentment_share
• presentment_click_rate_by_placement (carousel/banner/splash)
• first/last_presentment_ts, presentment_recency_days

2. Email features

• emails_sent_{30,90,365}d, email_opens_{30,90,365}d, email_clicks_{30,90,365}d
• email_open_rate, email_click_rate, time_since_last_open
• promo_response_rate (orders/applications within X days of promo email)

3. Portal/App engagement

• impressions_{15,30}d, portal_clicks_{15,30}d, portal_ctr
• device_type_share, session_duration_median, unique_sessions_{15,30}d

4. Application & response labels

• Use applications as the canonical response source. Compute applied_within_30d etc. Ensure application timestamps are after exposure for causal evaluation if needed.

5. Transaction & cross-product signals (if available)

• recent_spend_{30,90}d, txn_count_{30,90}d, avg_txn_value
• card_product_holdings (has_other_cards, has_deposit, has_loan) — cross-sell signals

6. Customer behavior & utilities

• recency_days (last presentment/last email open), has_recent_exposure_15d flags
• rolling-window counts: 7/15/30/90/365 day aggregates for exposures & interactions
• decay_weighted_exposures (exponential decay), exposure_share_card_vs_other

7. Session-level and deduplication

• De-duplicate presentments by presentment_id or by (session_id, placement) before counting exposures
• presentments_per_session, unique_presentments_per_session

8. Placement & product-level features

• placement_ctr_carousel, placement_ctr_banner, placement_ctr_splash
• product_shown_share_card, product_shown_share_loans

9. Interaction & derived features

• exposure_x_recency (exposures * 1/(1+recency_days)), click_rate_per_exposure
• exposure_to_apply_conversion per campaign and per channel

10. Trended features & slopes

• presentment_count_slope_30d (linear fit on daily presentment counts)
• week-over-week and month-over-month ratios for clicks and applies

11. Risk & fraud flags (banking contexts)

• recent_declines_{30,90}d, fraud_flag_recent, chargeback_count_{365}d — use carefully and time-truncate for causality concerns

12. Branch & CRM proxies for physical-mail responses

• branch_visits_{30,90}d, crm_contact_count, crm_sentiment_recent

Leakage & cautions (banking-specific)

• Do NOT use application approval/decision fields as inputs for a model that predicts application or approval.
• Presentments that only appear after an application or after approval are direct leakage.
• Settled vs unsettled transactions: refunds/chargebacks settle late; apply settlement_buffer_days when including refunds as features.
• Bureau or third-party pulls: only use pulls with pull_ts <= cutoff_date.

Implementation notes

• Build feature functions that accept (events_df, cutoff_date, windows=[]) and return per-customer aggregates; unit-test each function for off-by-one and leakage.
• Persist intermediate per-window aggregates in date-partitioned tables for efficient backfill and feature serving.
• Save feature_spec.yaml documenting each feature name, description, window, denominator, and encoding.

Evaluation & monitoring

• Metrics: PR-AUC (recommended for imbalanced positive response), calibration, and business lift (response rate uplift vs baseline).
• Use campaign-level holdouts, randomized holdout groups, or A/B tests to measure incremental response.
• Monitor feature drift and distributional shifts by snapshotting daily feature aggregates.

Quick developer checklist

• Confirm canonical table mappings and timestamp columns.
• Implement families incrementally and run assert_no_future_leakage after each family.
• Add unit tests for edge cases: zero denominators, missing customers, late-arriving events.
• Provide a small exploratory notebook (already included) and example SQL snippets for ETL colleagues.

References

• See references/schema.md and references/leakage.md in this folder for schema and leakage details.

Keep this skill focused on feature families, tests, and feature-serving artifacts. Domain and data-generation details remain in synthetic-data-skill.

If you'd like, I will implement the following now: rolling-window trends, exposure-share features, decay-weighted counts, and session-deduped presentment metrics in customer-marketing-response/scripts/marketing_response_features.py and add unit tests. Reply with which items to prioritize.