Outcome Attribution Schedule.

1. Background and scope

This Outcome Attribution Schedule (the “Schedule”) supplements the Data Processing Agreement (the “DPA”) between The Sweet Note, Inc., a Delaware corporation operating the SweetNote B2B platform (“SweetNote”), and the business customer (“Customer”) that engages SweetNote to deliver one or more recipient campaigns with the Outcome Attribution feature enabled.

This Schedule is incorporated by reference into the DPA and the underlying Master Services Agreement (the “MSA”). All defined terms not redefined in this Schedule carry the meanings given in the DPA. Where this Schedule and the DPA conflict on the specific subject of Outcome Attribution Conversion Data, this Schedule controls. For all other subjects, the DPA controls.

This Schedule is entered into under the same US Data Protection Laws referenced in DPA Section 1: the California Consumer Privacy Act and California Privacy Rights Act (CCPA / CPRA), the Illinois Biometric Information Privacy Act (BIPA), the Virginia Consumer Data Protection Act (VCDPA), the Colorado Privacy Act (CPA), and the other state data-protection laws enumerated there. SweetNote serves US-based Customers and US-resident recipients; this Schedule does not extend the territorial scope of the DPA.

2. Definitions

• Conversion Data means a record submitted to SweetNote describing a downstream conversion event attributable to a recipient who received a SweetNote campaign with Outcome Attribution enabled. Each Conversion Data record consists of exactly four fields on ingestion: (i) a join key (either the signed sn_ref token described in Section 4 or the pair campaign_id + recipient_token); (ii) the value of the conversion (a numeric amount in the campaign's declared currency, a count, or a Boolean indicator); (iii) the currency declared for the campaign; and (iv) the timestamp at which the conversion occurred. Any additional fields submitted alongside a Conversion Data record are field-filtered and discarded on ingestion, before any data is written to disk. Proactive monitoring that flags a sustained pattern of unexpected fields to the Customer’s technical contact is planned for the Outcome Attribution service.
• Outcome Attribution means the optional feature of the SweetNote service that ingests Conversion Data, attributes it to the campaign that preceded it within a locked attribution window, and reports the result back to Customer as an aggregate Outcome KPI on Customer's dashboard, deck, and readout PDF.
• Attribution Window means the platform-locked two-layer window during which Conversion Data is accepted and attributed: a Primary Attribution window of days 0–30 post-activation, an Extended Observation window of days 31–90 post-activation, and a hard cap rejecting any Conversion Data with a timestamp later than activation + 90 days. The Attribution Window is uniform across every methodology SweetNote offers and is not Customer-configurable.
• Customer Payment Processor means the third-party platform Customer uses to process the conversion event. Examples include Stripe, Givebutter, Classy, Donorbox, and similar providers; the supported processors at any given time are documented in the SweetNote portal Integrations section. Customer Payment Processors are Customer's subprocessors, not SweetNote's; SweetNote does not hold a direct contractual relationship with any Customer Payment Processor on behalf of Customer.
• Conversion Aggregate means the per-cell increment-only triple (count, Σvalue, Σvalue²) SweetNote maintains for each (campaign, cohort, variation) combination. The Conversion Aggregate is the durable representation of Conversion Data inside SweetNote, sufficient to compute means and confidence intervals without retaining any per-recipient amount.
• Sample-Floor Suppression means SweetNote's standing rule that, for each (campaign, cohort, variation) cell, the Outcome KPI rate and its confidence interval are published only at n ≥ 25 attributed conversions. Below the floor the cell's attributed-conversion count remains visible, but the rate and its confidence interval are withheld (suppressed, not estimated) and the cell is marked “Collecting.” This is the same three-tier floor SweetNote applies uniformly across the platform: the underlying facts (counts) stay visible, and only the inferential rate and interval gate at n ≥ 25.
• Identity Match CSV means a Customer-uploaded CSV file with three required columns — join key, amount, and timestamp — and, optionally, a currency column, that Customer supplies as an alternative to a Customer Payment Processor webhook when the conversion happens off-platform (e.g., a mailed-in donation processed manually). The conversion currency is taken from the campaign's declared currency; where the optional currency column is present, each non-empty value is cross-checked against that declaration and then discarded with the rest of the field-filter residue. On ingest SweetNote validates each amount for numeric type and validates the row against the campaign's declared currency and outcome type, rejecting rows that fail validation.
• Token Map means the pseudonymous recipient_token → (campaign, cohort, variation) mapping SweetNote retains to resolve Conversion Data to the correct attribution cell. The Token Map's absolute retention ceiling is 120 days post-activation, after which SweetNote deletes the map’s lookup key and cohort tags for that campaign and refuses any later Conversion Data for it, per Section 8.

3. Roles of the parties

The DPA's allocation of roles applies to Conversion Data without modification: Customer is the Data Controller (or a Business under CCPA / CPRA) and SweetNote is the Data Processor (or a Service Provider under CCPA / CPRA). Customer determines the purpose of measuring the conversion outcome, configures its conversion-reporting flow (the Webhook, Click-token, or Identity-Match CSV path), and supplies the join key that ties a conversion event to a recipient.

SweetNote processes Conversion Data solely on Customer's documented instructions. SweetNote does not retain, use, sell, share, or disclose Conversion Data outside the direct business relationship with Customer; does not combine Conversion Data with data from other Customers; and does not use it for SweetNote's own commercial purposes. Conversion Aggregates are per-brand only, never pooled into the cross-tenant benchmark dataset described in DPA Section 4.

4. Scope and nature of processing

Subject matter

Ingestion, attribution, aggregation, and dashboard reporting of conversion events Customer's recipients complete downstream of a SweetNote campaign that has Outcome Attribution enabled.

Duration

For the term of each campaign on which Customer enables Outcome Attribution, plus the retention period described in Section 8. This Schedule's term runs concurrently with the DPA.

Nature and purpose of processing

(a) Receiving Conversion Data via one of three integration paths: the Webhook path — the authenticated POST /v1/conversions endpoint, called by Customer’s own server or webhook handler (typically relaying the event Customer’s payment processor delivered to it, with the join key carried in the processor’s metadata field; a Customer system may also post a conversion it recorded directly); the Click-token path — the signed sn_ref token SweetNote appends to Customer’s call-to-action link, which Customer’s conversion page carries through and forwards in the same POST /v1/conversions request; or the Identity-Match CSV path — a Customer-uploaded CSV file when the conversion happens off-platform. (b) Verifying the join key resolves to a Customer-owned campaign with Outcome Attribution enabled. (c) Verifying the conversion timestamp falls within the Attribution Window. (d) Verifying the declared outcome_type and currency match the campaign declaration. (e) Incrementing the Conversion Aggregate for the resolved (campaign, cohort, variation) cell. (f) Discarding the per-recipient value before any data is written to disk. (g) Surfacing the Outcome KPI on Customer’s dashboard, deck, and readout PDF, subject to Sample-Floor Suppression.

Categories of Data Subjects

The same Categories of Data Subjects described in DPA Section 4, Customer's employees, donors, clients, customers, partners, event guests, members, or similar individuals to whom Customer addressed the underlying SweetNote campaign.

Categories of Conversion Data

• Join key: a signed sn_ref token (the Click-token path) or the pair campaign_id + recipient_token (the Webhook and Identity-Match CSV paths). Pseudonymous; resolves to a recipient cell on SweetNote’s side but carries no name or address.
• Conversion value: numeric (currency, count, or Boolean) for the duration of the request transaction only; the per-recipient value is not written to disk. Only the incremented Conversion Aggregate persists.
• Currency: must match the campaign's declared currency; mismatches are rejected with HTTP 409.
• Timestamp: the occurred_at field on the Conversion Data record. Used to verify the conversion fell within the Attribution Window.
• Source attribution: an enumerated source value drawn from the supported-processors list published in the SweetNote portal Integrations section (e.g., stripe, givebutter, classy, donorbox, pixel, csv, and additional processors as they are added), used to mark the data-quality tier of the Conversion Data record. New supported sources are added without amendment to this Schedule.

Categories of Conversion Data NOT collected

SweetNote does not collect, store, or process any of the following through the Outcome Attribution feature:

• Per-recipient transaction amounts past the request transaction. The per-recipient amount is used solely to increment the Conversion Aggregate within the same request and is discarded thereafter.
• Recipient identifying data inside the conversion event. Customer's Customer Payment Processor records will contain such data; SweetNote does not request or store it.
• Recipient browsing or device data from the conversion site. SweetNote does not place any tracking pixel, cookie, or fingerprinting code on Customer’s conversion site. On the Click-token path the sn_ref token travels as a parameter on the link the recipient follows; Customer’s own page carries it through to Customer’s server, which forwards it with the POST /v1/conversions request. SweetNote does not directly access Customer’s site.
• Conversions beyond the 90-day cap. Any Conversion Data record with an occurred_at later than activation + 90 days is rejected with HTTP 409 and not written.

5. Lawful basis and consent

Customer's lawful basis for processing the underlying recipient relationship is established by the DPA (Customer's documented business purpose for engaging recipients). This Schedule does not introduce a new lawful-basis requirement; the recipient's downstream conversion event is a transaction Customer is already entitled to process under its existing relationship with the recipient.

On a study that uses a SweetNote-hosted reveal page, recipient consent to SweetNote’s role in the conversion event is captured by the reveal-page consent infrastructure described in the privacy notice §5 (analytics-consent ribbon plus action-as-consent for the recipient’s reaction and CTA-click). On a direct-delivery study (DPA Section 4A), Customer provides any notice and consent its own page requires, and the click-reference path is not available. The Outcome KPI displayed on Customer’s dashboard reads only the aggregated (campaign, cohort, variation) cell, not the individual recipient’s conversion, and is therefore covered by the same consent posture.

Version-pinning of the consent posture. The consent language at thesweetnote.com/legal/privacy.html §5, as published on the Effective Date of this Schedule, governs recipient consent for Conversion Data purposes for events ingested from that Effective Date forward. SweetNote maintains a versioned archive of the privacy notice at legal/privacy-archive/ (each archived version is a self-contained HTML snapshot, named by the Effective Date of the version it replaces). On Customer’s written request, SweetNote will provide the privacy notice version that was in force at the time of any specific conversion event, returned within ten (10) business days of the request. If SweetNote materially updates the consent infrastructure described in §5 of the privacy notice during the term of this Schedule, the changed version takes effect for Conversion Data ingested from the change’s effective date forward; consent for previously-ingested events remains governed by the version then in force.

Customer attests that any recipient-facing disclosure required by Customer's own privacy notice (e.g., “we measure whether your scan led to a donation”) is the Customer's responsibility and is delivered through Customer's own channels (privacy policy, terms of use, donor stewardship communications).

6. Subprocessors

SweetNote engages the same subprocessors for Outcome Attribution that it engages for the base SweetNote service. The current SweetNote subprocessor list is published at thesweetnote.com/legal/subprocessors. Outcome Attribution does not introduce SweetNote-side subprocessors beyond those already disclosed there.

Customer Payment Processors are Customer's subprocessors, not SweetNote's. When Customer wires a payment processor (Stripe, Givebutter, Classy, Donorbox, or similar) into the Outcome flow, the processor delivers each conversion event to Customer's own webhook handler, and Customer's handler relays the join-key-plus-aggregate fields to SweetNote's POST /v1/conversions endpoint. Except for a booking tool Customer connects directly (the cal.com connector), the processor itself never calls SweetNote. When Customer connects its own cal.com account, cal.com sends each booking event to SweetNote’s connector endpoint; SweetNote reads only the booking identifier, the attribution reference (sn_ref) and the time the booking was made, discards the rest of the event without storing it, and records the conversion under the Click-token path rules. SweetNote does not hold a contractual relationship with Customer's Customer Payment Processor; Customer's own DPA with that processor governs the processor's handling of the underlying conversion record. SweetNote acts as a pass-through endpoint that ingests the fields Customer relays. Customer represents and warrants that (a) Customer's DPA with its Customer Payment Processor permits Customer's onward relay of the four-field Conversion Data described in Section 2 to SweetNote; and (b) Customer's recipient-facing privacy notice discloses (or will disclose before the first conversion event is sent) that conversion data is shared with SweetNote for outcome-attribution purposes.

If SweetNote engages a new SweetNote-side subprocessor that handles Conversion Data, SweetNote will provide Customer with at least 30 days' prior written notice in accordance with DPA Section 8.

7. Data minimization and aggregation

Outcome Attribution is engineered as an increment-only aggregator. The architectural guarantee is that no per-recipient conversion amount persists beyond the request transaction that ingested it. Specifically:

• On ingestion at POST /v1/conversions, SweetNote field-filters the request body to the four declared fields (join key, value, currency, timestamp) plus the declared outcome type, the enumerated source attribution and the idempotency key.
• The join key is resolved against the Token Map to identify the target (campaign, cohort, variation) cell.
• The cell's Conversion Aggregate is incremented: count += 1, Σvalue += value, Σvalue² += value². These three running quantities are sufficient to compute the cell's mean and variance / Wilson-style confidence interval for the readout.
• The per-recipient value is then discarded. No per-recipient conversion amount is written to disk. SweetNote records only, on the recipient’s pseudonymous record, the time that recipient’s first attributed conversion in each window was recorded (no amount), so a recipient who converts more than once is counted once. These markers are deleted with the Token Map at the 120-day ceiling, or on an erasure request.
• Two keys are stored to deduplicate replays: the idempotency key Customer sends with each request, stored as sent, and a cross-path key that is a keyed digest (HMAC-SHA-256) of the conversion's identifying inputs. Customer should not put personal data or amounts in its idempotency key. The key material is held in the application environment and never in the database, so the stored digest cannot be reversed by anyone holding the database alone.

The Outcome KPI displayed to Customer reports the Conversion Aggregate for each cell, subject to Sample-Floor Suppression: below n ≥ 25 attributed conversions per cell, the cell's attributed-conversion count remains visible while the Outcome KPI rate and its confidence interval are withheld (suppressed, not estimated) and the cell is marked “Collecting.”

The aggregation model achieves data-minimization by construction: with full database access, and without the separately-held key material described above, no analyst at SweetNote could identify how much any particular recipient converted. Two things make that true together, and the second is not incidental: the per-recipient value is never written, and the deduplication digest computed over it is keyed rather than a plain hash. A plain hash would not have been enough — every other input to it (campaign, recipient row, date) is ordinary stored data, and a conversion amount carries little enough entropy to be recovered by exhaustive search. Keying the digest is what closes that path.

8. Retention and deletion

This Schedule establishes the following retention horizons for the data types Outcome Attribution introduces:

• Conversion Aggregates (per-cell count, Σvalue, Σvalue²), retained 24 months from activation, to support period-over-period program comparisons. The settled Outcome results frozen when the Attribution Window closes (counts and floored rates, no recipient identifiers) are kept with the settled study report under DPA Section 13, with no fixed end date, and are deleted with it on request. Aggregates are pseudonymous (no recipient identifier inside them) and Customer-scoped.
• Token Map (the recipient_token → (campaign, cohort, variation) mapping needed to resolve incoming Conversion Data), retained for 90 days post-activation (the full Extended Observation window so day-89 conversions can still resolve) plus a 30-day closeout buffer, giving a hard upper bound of 120 days post-activation. The Token Map is Personal Data in pseudonymized form — it contains the recipient’s pseudonymous token (a randomly generated identifier) paired with the cell coordinates, with no direct identifiers (no name, email, address, or any field that could re-identify the recipient without joining against Customer’s own records). SweetNote treats the Token Map as Personal Data subject to the protective controls in DPA Sections 7 (security), 10 (data-subject rights including pseudonymization), 11 (breach notification), and 13 (retention). The Token Map is managed under a strict 120-day hard retention ceiling — shorter than other Personal Data categories described in DPA Section 13 — given its narrow function (attribution-cell resolution within the bounded 90-day Extended Observation window) and limited identifier surface. After 120 days SweetNote deletes the Token Map’s lookup key and the cohort tags for each recipient of that campaign, and refuses any later Conversion Data for that campaign (HTTP 409). The arm assignment is kept on the recipient’s pseudonymous record so the randomization can be audited. The ceiling is code-enforced: the retention configuration is bounded by a database constraint that will not permit the Token Map ceiling to be set above 120 days. The sole exception is a legal-hold or compelled-process retention required by applicable law (for example, a preservation obligation, a subpoena, or other compelled legal process). Where such an obligation applies, the affected Token Map may be retained beyond 120 days solely to the extent and for the period legally required, under the same protective controls, and is deleted immediately once the hold or obligation lifts; SweetNote documents the basis in writing on request.
• Stored idempotency keys: retained 120 days (the Token Map ceiling), so a conversion reported twice, by different paths, during the 90-day window is counted once; then deleted.
• Per-recipient conversion amounts: never persisted past the ingest request transaction. The architectural guarantee in Section 7 makes this a structural property, not a policy commitment.

Customer-initiated deletion. On Customer's written request, or on termination of the underlying MSA, SweetNote will delete Conversion Aggregates for the affected campaign(s) within thirty (30) days of the request, except where retention is required by applicable law.

Recipient pseudonymization request. On a verified erasure or pseudonymization request under DPA Section 10, SweetNote suppresses the recipient and ceases use of that recipient's data for the study: the recipient's identifying data and engagement events are erased, and any inbound Conversion Data for the suppressed recipient is rejected and not written. SweetNote enforces this through its erasure/DSAR process within the Section 10 service level. Previously-incremented Conversion Aggregates remain (they carry no recipient identifier and cannot be re-attributed to the recipient).

9. Security measures

The technical and organizational measures described in DPA Section 7 apply in full to Conversion Data and the infrastructure supporting Outcome Attribution. In addition, the Outcome Attribution endpoint and infrastructure are subject to the following specific controls:

• The POST /v1/conversions endpoint is authenticated with the Customer's tenant secret API key and the dedicated conversions.write scope. The API key may be rotated by Customer at any time from the SweetNote portal; the previous key is honored for 24 hours after rotation to prevent in-flight conversion drops, then revoked.
• All request bodies are transmitted over TLS 1.2 or higher.
• Field-filtering on ingest is implemented as an allow-list, not a deny-list. Only fields in the declared schema are read and written; any other field in a request is ignored and is never persisted or logged.
• Request bodies are not retained beyond the request transaction. Server logs capture only the enumerated source, the campaign ID, the resolved cell coordinates, the stored idempotency key, and the response status, never the per-recipient amount.
• The Token Map is stored encrypted at rest (AES-256 envelope, per DPA Section 7) and queried only by the conversion ingest service. The mapping is not a standalone table: it is carried as columns on the recipient record, which has row-level security enabled with a tenant-scoped read policy — every read is constrained by the database to rows belonging to the querying party’s own tenant, rather than relying on a query never being written. No SweetNote operator dashboard or support surface exposes these columns, and the aggregate-only architecture in Section 4 means they are never required to produce a Conversion Aggregate for reporting.
• The Conversion Aggregate tables carry row-level security scoped to the tenant and are queried only with Customer-scoped credentials, so a read can only ever return that Customer’s own cells.

10. Customer obligations

Customer assumes the following responsibilities specific to Outcome Attribution:

• Webhook configuration. If Customer’s payment processor supports outbound webhooks, Customer points the processor’s webhook at Customer’s own handler, and that handler relays each conversion event to POST /v1/conversions with the conversions.write scope, carrying the join key (the campaign_id + recipient_token pair) from the processor’s metadata field, per the integration documentation in the SweetNote portal Integrations section. Customer is responsible for maintaining the integration; SweetNote does not modify the Customer’s payment-processor configuration.
• Click-token configuration. If Customer uses the Click-token path, SweetNote appends a signed sn_ref token to Customer’s call-to-action link when the recipient taps it. Customer is responsible for carrying that token through Customer’s own conversion flow and forwarding it with the POST /v1/conversions request. Where Customer chooses to persist the token between page loads, Customer is responsible for doing so in a manner that survives browser privacy controls; a JavaScript-set first-party cookie capped at seven days by Safari ITP will silently break delayed conversions and is not a supported integration path.
• Identity-Match CSV. If Customer uses the Identity-Match CSV path, Customer is responsible for ensuring the uploaded CSV contains the three required columns (join key, amount, timestamp) — plus, at Customer’s option, a currency column, which SweetNote cross-checks against the campaign’s declared currency and then discards — and that any other columns Customer’s source system attaches are stripped before upload. The conversion currency is taken from the campaign’s declared currency; SweetNote validates each amount for numeric type and validates each row against the campaign’s declared currency and outcome type, rejecting rows that fail validation, and field-filters on ingest as a defense in depth. Customer’s own minimization at source remains the primary control.
• Privacy-notice disclosure. Customer is responsible for any recipient-facing disclosure that Customer's privacy policy or applicable law requires concerning the conversion-measurement flow. Recommended language is provided in thesweetnote.com/security; Customer is not required to use SweetNote's recommended language but is responsible for the adequacy of Customer's own disclosure.
• Attribution window declaration. Customer acknowledges that the Attribution Window is platform-locked at 30 days primary + 31–90 days extended observation + day-90 hard cap and is not Customer-configurable. Customer's recipient-facing disclosure must not represent any longer attribution window.
• Currency and outcome type declaration. Customer declares the campaign's currency and outcome type at scoping. Conversion Data records with a mismatched currency or outcome type are rejected; Customer is responsible for submitting conversions consistent with those declarations, on whichever integration path Customer uses.

11. Data subject rights

The DPA Section 10 obligations apply to Conversion Data subjects without modification. SweetNote will assist Customer in responding to a Data Subject request (access, deletion, pseudonymization) by:

• Suppressing the affected recipient's recipient_token in the Token Map, blocking future Conversion Data ingestion for that recipient.
• Confirming in writing that no per-recipient conversion amount exists in SweetNote's systems (the architectural guarantee in Section 7 makes this confirmation universal), and deleting the recipient's first-conversion markers.
• Confirming which integration paths SweetNote accepts for the campaign; Customer identifies which of its processors received the recipient’s sn_ref token (Customer maintains the relationship with each processor and is responsible for downstream deletion in those systems).

Because per-recipient conversion amounts are never written, a Data Subject request for “all conversion data SweetNote holds about me” is satisfied by the confirmation that none exists in SweetNote's records. The Conversion Aggregate at the cell level carries no recipient identifier and is not subject to a deletion request from any single Data Subject.

11.1 Opt-out signals and Global Privacy Control. Two layers of opt-out apply to Conversion Data. At the reveal: on a recipient’s consent decline or a Global Privacy Control (GPC) signal, no sn_ref attribution reference is carried on the call-to-action, so no conversion can be click-attributed from that session (the same kill-switch posture as the privacy notice §5 consent architecture). After the fact: where Customer receives an opt-out of sale or sharing, a GPC-triggered opt-out under an applicable US state privacy law, or any equivalent signal concerning a recipient, Customer routes it to SweetNote through the same channel as a Data Subject request, and SweetNote suppresses the affected recipient_token in the Token Map (blocking all future Conversion Data ingestion for that recipient) within the DPA Section 10 SLA. Conversion Data is processed by SweetNote solely as Customer’s Service Provider; SweetNote does not sell or share Conversion Data within the meaning of the CCPA / CPRA.

12. Security incident response

The 72-hour notification commitment in DPA Section 11 applies in full to any Security Incident affecting Conversion Data or the supporting infrastructure. Because Conversion Data does not persist per-recipient values, the practical scope of a Security Incident involving Conversion Data is narrower than for the underlying recipient PII: the worst-case breach exposes Conversion Aggregates (pseudonymous, no recipient identifiers) and the Token Map (pseudonymous, useful only in combination with Customer's own records). SweetNote's incident-notification will characterize the affected data types and exposure surface accordingly.

13. Audit rights

Customer's audit rights under DPA Section 12 extend to SweetNote's Outcome Attribution infrastructure. Most audit requests will be satisfied by SweetNote providing:

• Architectural documentation of the increment-only aggregator described in Section 7 (available under NDA on request).
• Sample request logs demonstrating that per-recipient values do not appear in persistent logs.
• Token Map retention-job evidence demonstrating the 120-day deletion runs as specified in Section 8.
• Responses to Customer's information-security questionnaire (SIG, CAIQ, custom) covering the Outcome Attribution-specific controls.

14. Termination

This Schedule terminates automatically when Customer disables Outcome Attribution on all of Customer's campaigns and SweetNote completes the deletion of Conversion Aggregates and Token Maps for those campaigns per Section 8.

Customer may disable Outcome Attribution on a per-campaign basis by request to SweetNote support (support@thesweetnote.com); SweetNote effects the disable within five (5) business days of the request. Disabling Outcome Attribution stops the ingestion of new Conversion Data; previously-incremented Conversion Aggregates continue to be reported to Customer's dashboard until campaign close and to be retained for the 24-month rolling period described in Section 8 unless Customer requests earlier deletion.

This Schedule may also be terminated at any time by either party on 30 days' written notice. On termination, SweetNote will (at Customer's option) either return Customer's Conversion Aggregates and Token Map metadata to Customer in a commonly used format, or securely delete them per DPA Section 13.

15. Limitation of liability

Each party's liability under this Schedule is subject to the limitations and exclusions set out in the underlying MSA §9 and DPA §15. For clarity, claims arising from a Security Incident or data breach involving Conversion Data, the Token Map, or any other data processed under this Schedule are subject to the Data-Protection Cap in MSA §9.2(a), consistent with the cross-reference structure in DPA §15. Direct damages arising from a SweetNote breach of this Schedule, including breach-response costs, regulatory fines properly assessed against Customer, notification costs, and credit-monitoring services for affected recipients, are direct damages and are not excluded by the MSA consequential-damages waiver. Nothing in this Schedule excludes or limits either party's liability for (a) breach of confidentiality obligations, except that a claim arising from a Security Incident, data breach or other violation of this Schedule or the DPA is governed by the Data-Protection Cap as MSA §9.3(a) provides, even where it is also characterized as a breach of confidentiality, (b) gross negligence, fraud, or willful misconduct, or (c) liabilities that cannot be excluded under applicable law.

16. Term, survival, and changes

This Schedule enters into force when both parties have executed it (by in-portal clickwrap acceptance, with SweetNote's counter-signature applied automatically; a dual counter-signature is available on request) and remains in force for so long as SweetNote processes Conversion Data on Customer's behalf. Sections 7 (Data minimization), 8 (Retention and deletion), 9 (Security measures), and 12 (Security incident response) survive termination.

SweetNote may update this Schedule where required to comply with applicable law or to reflect material service changes; substantive changes are communicated to Customer with at least 30 days' notice and require Customer's written acceptance to take effect. The Attribution Window described in Section 2 is a material term and will not be modified without Customer's written acceptance.

17. Governing law and jurisdiction

This Schedule is governed by the law of the jurisdiction specified in the underlying MSA. Disputes are resolved in the forum specified in the MSA. Where the MSA does not specify, this Schedule is governed by the laws of the State of Delaware.

18. Contacts

SweetNote / The Sweet Note, Inc.
Data Protection contact: privacy@thesweetnote.com or legal@thesweetnote.com
Security incident contact: security@thesweetnote.com
DSAR routing: privacy@thesweetnote.com or legal@thesweetnote.com (both addresses reach the same intake queue)
Outcome Attribution integration support: support@thesweetnote.com

19. Execution

This Schedule is executed by both parties alongside the underlying MSA and DPA, by in-portal clickwrap acceptance at checkout (fully enforceable under E-SIGN and UETA); SweetNote's counter-signature is applied automatically and a counter-signed PDF copy is generated for the Customer's audit file, and a dual counter-signature is available on request. Execution occurs before the first conversion-enabled QR code is generated; no Conversion Data ingestion is possible until this Schedule is in force. This Schedule is offered as published, same paper for every brand, and is not redlined.

On optional methodology review. Outcome Attribution is SweetNote's most data-sensitive feature, so SweetNote recommends — but does not require — an optional methodology review before a larger or higher-stakes Outcome study goes live. The review follows the standard posture — opt-in below $10,000, included by default (and declinable) at $10,000 and above and on every Gift Lift study — and does not gate execution; a Customer that wants to move entirely self-serve can. Counter-signature, likewise, is available on request rather than imposed by study size.

On the Outcome Attribution add-on price. Outcome Attribution is included at no charge on any study; there is no separate add-on charge. It remains an explicit opt-in — the Customer enables it at scoping and executes this Schedule — so the data-processing terms of this Schedule are affirmatively accepted before any conversion data is ingested. See pricing.html for the formula breakdown.

How this fits the rest of the SweetNote paper. This Schedule extends the DPA to cover the additional inbound data flow that Outcome Attribution creates. It does not replace any part of the DPA; the base DPA applies in full to the underlying recipient relationship. It does not extend the territorial scope of SweetNote's service (US-only at launch, per DPA Section 9). The Attribution Window's data-minimization boundary (Section 2) is the structural commitment that makes Outcome Attribution defensible across every Customer regardless of methodology choice, no Customer-by-Customer negotiation of how long SweetNote holds per-recipient conversion exposure.