Methodology

The Creator Deal Terms Index is produced from records held in CollabBook on behalf of creators who use the platform to manage their brand deals. It is not a survey. Creators do not self-report summary statistics; the underlying records are deal objects, obligation objects, and brand-review objects created as part of normal product use.

The data originates from three schema tables:

• deals -- deal type, platform, status, and contract timestamp. Kill-fee and payment-readiness booleans are present in the schema but excluded from publication (see §Known data gaps).
• obligations -- structured payment milestones, usage-expiration dates, exclusivity-expiration dates, paid-at timestamps, and payment-due-trigger labels (free text).
• brand_reviews -- post-deal reviews submitted voluntarily by creators after a deal is marked complete, including revision rounds, scope changes, usage-rights adherence, and payment timing.

Contract text, AI analysis outputs, creator names, brand names, deal values, and contact details are never read, queried, or included in any aggregation.

The index applies k-anonymity: every published cell must represent at least 10 distinct creators (distinctcreator_id values). A bucket with 3 deals from 3 creators, for example, falls below the threshold even though it has the same row count as one with 10 deals from 3 creators.

Cells below the threshold appear as "Insufficient data" in the published output. No interpolation, rounding-up, or extrapolation is ever applied to reach a threshold.

The following identifiers are never published under any circumstance: creator ID, brand name, brand ID, deal ID, contact name, contact email, individual deal value, contract text, or AI analysis content.

The index applies a two-tier consent model.

Deal and obligation data (implicit consent): Aggregate queries against deal-type, platform, status, kill-fee flags, obligation types, and timestamps are permitted without per-row opt-in. Published output from these tables contains no PII. Creators may request an opt-out from their account settings (this control is planned as a near-term product refinement).

Brand-review data (explicit consent required): The brand-review table includes a consent_aggregation boolean. Only rows where this field is true are included in any aggregation. Reviews submitted without checking the consent box are never read by the aggregation process, regardless of any other condition.

Some obligation records carry a sentinel value of year 9999 in the due_at column. This sentinel represents an obligation that is "triggered by an event" rather than bound to a calendar date -- for example, a payment due "on client approval" where the approval date is not yet known.

All aggregation queries exclude rows where due_at >= 2999-01-01. Duration metrics derived from obligation timestamps are invalid for sentinel rows. Sentinel rows are not counted toward data-point totals or denominator calculations.

The payment_due_trigger field on obligation records is free text written by creators when they record a payment milestone (examples: "net 30", "on signing", "50% upfront", "upon delivery").

The aggregation script normalizes this field using a conservative regex parser. Recognized patterns:

• net [N] -- any number of days (e.g. "net 30", "net-45")
• on signing / upon signing
• on delivery / upon delivery
• on approval / upon approval
• [N]% upfront
• [N]% on signing
• [N]% on delivery

Patterns that do not match are excluded from the net-terms distribution metric. The quarterly JSON includes the parser recognition rate (the percentage of all triggers that matched a recognized pattern). The recognition rate is suppressed as "insufficient_data" when fewer than 10 distinct creators have any payment trigger in the window; otherwise it is published as a percentage. The raw unrecognized count is never published (it has no associated k value and cannot be k-gated). If the recognition rate is below 60%, the net-terms metric is disclosed as low-confidence in the index page.

Percentile distributions (p25/p50/p75) use PostgreSQL's PERCENTILE_CONT aggregate. Percentages are rounded to one decimal place.

The k that gates a value must be the distinct-creator count of the exact subpopulation the value is computed over — not a broader parent population.

• Eligible-population k — for nullable fields: COUNT(DISTINCT creator_id) FILTER (WHERE field IS NOT NULL). A bucket of 15 creators where only 7 filled in kill-fee eligibility has k = 7 for that cell.
• Conditional-subpopulation k — for statistics computed over a filtered subset: the k is the distinct-creator count of that subset only. Example: median_days_late is computed only over obligations where paid_at > due_at, so its k is COUNT(DISTINCT creator_id) FILTER (WHERE paid_at > due_at). A bucket with 15 paid-obligation creators but only 5 who paid late suppresses the median even though late_rate_pct (gated on k = 15) is published.
• Sample-size counts — sample_sizes.total_deals_in_window and total_creators_in_window are both gated on the window distinct-creator count. When that count is < 10, both fields are published as "insufficient_data"— publishing a raw count for a sub-threshold population reveals the exact size of that group.

Two suppression shapes are used:

• Scalar cell suppression — a single computed value is replaced by "insufficient_data" when its k < 10. The surrounding row object remains; only the specific field is suppressed.
• Distribution bucket suppression — distribution arrays drop any individual bucket whose k < 10. When ALL buckets are dropped the distribution key itself becomes "insufficient_data"— never an empty array [].

Suppressed cells are never interpolated, replaced with industry estimates, or rounded toward a threshold. A suppressed cell means "we do not have enough data to publish this responsibly" — not "the number is roughly X."

Before any quarterly output file is committed to the repository, a reviewer confirms:

• The script ran against the production database, not a development snapshot.
• No suppressed cell was replaced with an estimate or interpolated value.
• Every published cell has at least 10 distinct creator IDs (verified via the sample_sizes object in the JSON).
• No brand name, creator name, deal ID, or contact field appears anywhere in the JSON or CSV.
• Sentinel dates were excluded (due_at >= 2999-01-01).
• Brand-review rows are filtered to consent_aggregation = true.
• The methodology page accurately describes the current net-terms parsing approach.
• The founder has reviewed the final output before the page goes live.

The Creator Deal Terms Index data (JSON and CSV files) is published under the Creative Commons Attribution 4.0 International license (CC BY 4.0). You are free to share and adapt the data for any purpose, including commercial use, as long as you give appropriate credit.

For questions about the methodology, data, or research program, contact us at research@collabbook.co.