Menu
Marketing domain knowledge: attribution models, engagement funnel order.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | domain-marketing |
| description | Marketing domain knowledge: attribution models, engagement funnel order. |
When aggregating engagement or spend metrics, drive FROM the event/activity table (messages, clicks, impressions), not the dimension table (contacts, accounts, campaigns). Contacts with zero engagements MUST NOT appear in engagement reports - they have no data to aggregate.
Exception - reports that JOIN two aggregations by a shared dimension: When a report groups metrics from multiple sources BY the same dimension (e.g., cost-per-acquisition by channel), the source with the MOST distinct values of that dimension defines the output population - INNER JOIN would silently drop dimension values that exist in one source but not the other. LEFT JOIN the smaller source onto the larger one. Dimension values without matching data in the smaller source get NULL metrics.
Attribution models split conversion credit across touchpoints. Implement the model the task or YML description specifies:
When a conversion has only one touchpoint, first-touch and last-touch are the same row - do NOT double-count credit.
Standard funnel: sent → delivered → opened → clicked → bounced. Each stage is a COUNT of events, not COUNT DISTINCT of recipients.
Do NOT deduplicate across funnel stages - one email opened 3 times is 3 open events.
Many API connectors (messaging, ads, telephony) store costs as negative
values (representing money leaving the account). Before writing SUM(price)
into a metric column, query SELECT MIN(price), MAX(price) on EACH source
table that contributes monetary values.
Single-source model: If the model reads monetary values from ONE source
only, preserve that source's sign convention. Do NOT apply ABS() - the
raw sign is the source of truth.
Multi-source model: If the model JOINs multiple tables that contain
monetary columns, check the sign of EACH monetary source with
SELECT MIN(price), MAX(price). If any two sources use different sign
conventions, normalize ALL monetary columns in the model to positive with
ABS() - including columns that come from a single CTE. Mixing positive
and negative conventions within one model produces misleading totals and
breaks comparisons between columns.
Load when working with Xata Postgres branches: forking a branch, building or testing dbt models on a branch, wiring dbt to a branch's credentials, diffing two branches, or the pre-merge impact report. Covers create_xata_branch, delete_xata_branch, get_dbt_profile, xata_branch_diff, schema_diff_branches, and pgroll migrations.
Load at Step 1 before exploring the project. Covers output shape inference, incremental model handling, and what to trust in YML.
Use this skill before writing any SQL query. Covers: output shape inference (cardinality clues from the question), efficient schema exploration, iterative CTE-based query building, structured verification loop (row count, NULL audit, fan-out check, sample inspection), error recovery protocol, saving output to result.sql and result.csv, turn budget management, and common benchmark traps.
Populate the knowledge base from dbt project research. Proposes entries across all 6 categories at org, project, and connection scopes.
Load FIRST before any dbt project work. Covers the full 8-step dbt workflow: project scanning, skill loading, validation, macro discovery, research, technical spec, SQL writing, and verification. Also covers output shape inference, incremental model handling, and what to trust in YML.
Loaded at Step 2 for the full workflow. Covers column naming, type preservation, JOIN defaults, lookup joins, sibling models, materialization, packages, and filtering rules.
