Data, analytics, and attribution

Raidz separates operational records, sensitive identity data, public chain facts, and derived analytics. Collection is purpose-limited and consent-aware.

Operational data

PostgreSQL models users, social accounts, wallet links, creator profiles, score snapshots, projects, campaigns, claims, deliverables, verification, settlement, services, reviews, attribution, Pons events, and policy versions.

Identity and tokens require stronger handling than ordinary marketplace configuration:

provider subjects are stored as HMAC-SHA-256 hashes using a runtime pepper;
X tokens are encrypted with AES-256-GCM under a runtime key;
wallet addresses are 20-byte values and signatures are stored only as hashes;
auth challenges expire, are single-use, and erase encrypted PKCE material when consumed;
raw secrets never belong in application logs or source.

Product analytics

The domain package defines typed creator and project funnel events across visit, intent, activation, marketplace, core value, retention, and referral. Examples include score start/receipt, connection completion, card sharing, mission claim, verified work, campaign draft, funding, deployment, verification, and repeat campaigns.

An event is valid only when:

analytics consent is granted;
schema and policy versions are present;
actor role matches the event definition;
timestamps and identifiers are valid;
retention is exactly 90 or 365 days as defined;
a deterministic deduplication rule is used.

Traffic source categories distinguish organic, partner, paid, operator, bot, internal, and unknown activity. This prevents owned/operator activity from being misreported as independent demand.

Attribution

The attribution model supports:

Event	Retention	Deduplication	Wallet consent
Click	90 days	Event ID	Not required
Registration	365 days	Campaign + creator + subject + event	Not required
Activation	365 days	Campaign + creator + subject + event	Not required
Wallet	365 days	Campaign + creator + subject + event	Required
Onchain	365 days	Chain + lowercase transaction hash + log index	Required

Every event includes occurrence/receipt time, pseudonymous subject, source, consent decision and time, policy version, retention, expiry, and event-specific properties. Events received before they occurred, events collected before consent, retention drift, and dedupe-key drift are rejected.

Limitations

An attributed event is an observed association under a declared model. It does not prove that the creator caused the action, that the user is unique across all contexts, or that the outcome has economic quality. Production reporting should disclose attribution window, identity resolution, exclusions, fraud rules, and model changes.

Planned pipeline

web/API/bot/chain observations
  → consent + schema validation
  → idempotent intake
  → PostgreSQL operational event
  → workflow enrichment/fraud review
  → ClickHouse consented aggregate
  → project and creator read model

This pipeline is specified in domain types and schema but is not deployed end to end.