# Customer Marketing Response

> Customer Marketing Response Skill

- Skill: `nageshwarreddyl/customer-marketing-response` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add nageshwarreddyl/customer-marketing-response`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nageshwarreddyl/customer-marketing-response/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: NageshwarReddyL (https://skillmd.com/u/nageshwarreddyl)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/nageshwarreddyl/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.