Recipient-Level Export Schedule.

1. Background and scope

This Recipient-Level Export 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 recipient-level export 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 the Recipient-Level Export, 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

• Recipient-Level Export means the optional feature of the SweetNote service that produces, on Customer’s request, a pseudonymous, recipient-level data file — delivered as a spreadsheet workbook (XLSX), or as a CSV file where workbook generation is unavailable — containing one row per recipient of a SweetNote campaign, keyed by the recipient’s Recipient Token, and carrying that recipient’s behavioral engagement facts, the recipient’s deliberate three-tap reaction, and the cohort tags and variation assignment Customer itself supplied. The Recipient-Level Export is delivered to Customer; it is not a SweetNote analytical surface.
• Recipient Token means the anonymous per-recipient identifier SweetNote derives with a secret key from its internal record for the recipient (it is not the QR code value). It is the sole identifier in the Recipient-Level Export. It carries no name, address, email, or other direct identifier, and it is meaningful only to a party that already holds the token-to-recipient mapping. SweetNote provides the token; Customer holds the mapping (Customer either uploaded the recipient list with the token, or SweetNote wrote the token back into Customer’s variable-data CSV at artifact generation).
• Pseudonymous Data means personal data that cannot be attributed to a specific data subject without the use of additional information kept separately, within the meaning of the EDPB’s pseudonymisation guidance and the additional-information separation principle. The Recipient-Level Export is Pseudonymous Data, not anonymous data: it remains personal data, and SweetNote and Customer treat it as such end-to-end.
• Behavioral Engagement Facts means the per-recipient funnel values carried in the export: whether the recipient opened the reveal, pressed play, clicked the action call-to-action, and returned; the recipient’s deliberate three-tap reaction (one of the stored keys loved / moved / smile — the recipient-facing labels Sweet / So sweet / The sweetest — or none); a coarsened time-to-open bucket; and a coarsened watch-depth bucket. None of these is a raw timestamp, a raw watch-second count, or an inferred-sentiment or biometric value.
• Coarsened Attribute means a value that SweetNote reduces to a discrete bucket before export — specifically, time-to-open (reported as one of eight day-scale ranges from “under one day” to “three weeks or more”) and watch-depth (reported as one of five percent-watched bands). No time-to-open range is narrower than one day. Coarsening is the structural control that defeats singling-out of a recipient by a unique raw value (Section 5); raw values are not offered.
• Cohort Pass-Through means the cohort_* tags and the variation assignment that Customer itself supplied in its recipient list, returned to Customer verbatim in the export. These are Customer’s own data; SweetNote neither defines nor enriches them.
• Retention Window means the period during which the Recipient-Level Export is generatable: from the close of the campaign’s engagement window through the thirty (30) day post-close Personal Data retention window described in DPA §13, after which the underlying per-recipient data (including the Cohort Pass-Through) is purged and the export can no longer be assembled.

3. Roles of the parties

The DPA’s allocation of roles applies to the Recipient-Level Export 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 analyzing its own recipient-level engagement data, requests the export, and holds the token-to-recipient mapping.

The Recipient-Level Export is the return of Customer’s own engagement data to Customer in a row-level grain, on Customer’s documented instruction. Once the export file leaves SweetNote and Customer re-joins it to Customer’s own recipient records, Customer is the Controller of the re-joined data on Customer’s systems, and Customer’s own privacy program governs it. SweetNote does not retain, use, sell, share, or disclose the Recipient-Level Export outside the direct business relationship with Customer; does not combine it with any other Customer’s data; and does not use it for SweetNote’s own commercial purposes. The recipient-level data is per-brand only, never pooled into the cross-tenant benchmark dataset described in DPA Section 4. For the avoidance of doubt, the Recipient-Level Export is a Customer-initiated pull of Customer’s own data by an authorized owner or admin user; it is not access by SweetNote personnel and does not alter SweetNote’s internal staff-access hard-wall (under which authorized SweetNote staff reach recipient-identifying Personal Data only through the logged data-subject-request path, per MSA §12.2 and privacy notice §9).

4. Scope and nature of processing

Subject matter

On Customer’s request, SweetNote assembles and returns to Customer a pseudonymous, recipient-level data file (a spreadsheet workbook, with a CSV fallback) of the engagement data for a SweetNote campaign that has the recipient-level export enabled.

Duration

For the term of each campaign on which Customer enables the recipient-level export, limited by the Retention Window in Section 2 and the retention horizons in Section 8. This Schedule’s term runs concurrently with the DPA.

Nature and purpose of processing

(a) Verifying that the requester is an authenticated Customer user with the owner or admin role for the campaign’s workspace. (b) Verifying that Customer has enabled the recipient-level export on the campaign and executed this Schedule. (c) Verifying that the request falls within the Retention Window. (d) Assembling, server-side, one row per recipient from SweetNote’s engagement-event store, joined to the Cohort Pass-Through and variation assignment Customer supplied. (e) Coarsening time-to-open and watch-depth to buckets and excluding all direct identifiers and re-identification keys (Section 5). (f) Returning the resulting data file (a spreadsheet workbook, with a CSV fallback), with an accompanying data dictionary, to Customer. (g) Writing an audit-log record of the generation.

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 data in the Recipient-Level Export

• Recipient Token: the anonymous join key. Pseudonymous; resolves to a recipient only on Customer’s side using the mapping Customer holds.
• Variation assignment and Cohort Pass-Through: the cohort_* tags and variation label Customer supplied, returned verbatim.
• Behavioral Engagement Facts: opened / played / clicked / returned indicators; the deliberate three-tap reaction; a coarsened time-to-open bucket; a coarsened watch-depth bucket.

Categories of data NOT included in the Recipient-Level Export

SweetNote does not include any of the following in the Recipient-Level Export:

• Direct identifiers. No name, postal address, email address, telephone number, IP address, geolocation, or device / user-agent string — ever.
• Platform-side re-identification keys. No SweetNote internal record identifier, session identifier, or QR-token value that SweetNote could use to re-attach identity is included.
• Raw timing or raw watch values. Time-to-open and watch-depth are Coarsened Attributes; raw timestamps and raw watch-seconds are not offered.
• Inferred sentiment or biometric data. The reaction is a deliberate, self-reported three-tap choice; SweetNote performs no facial, vocal, or affective inference of any kind (unchanged platform invariant; DPA §14.1).
• The token-to-identity mapping. SweetNote does not include the token-to-identity mapping in the export. On SweetNote’s side the token sits on the recipient record alongside any name or address Customer supplied only until those are deleted under DPA §13 (30 days after the engagement window closes).

5. Pseudonymisation and singling-out controls

The Recipient-Level Export is engineered to satisfy the three controls that make a pseudonymous, row-level export defensible:

• Pseudonymous form. The only identifier in the file is the Recipient Token. Every direct identifier is excluded by construction — the server-side assembly selects only the token, the Behavioral Engagement Facts, and the Customer-supplied Cohort Pass-Through, so a name or address cannot enter the file.
• Separation of the additional information. SweetNote does not include the token-to-identity mapping in the export. On SweetNote’s side the token sits on the recipient record alongside any name or address Customer supplied only until those are deleted under DPA §13 (30 days after the engagement window closes). The “additional information” needed to attribute a row to a person is held by Customer, separately, on Customer’s side.
• Technical and organizational measures. The measures in DPA Section 7 apply in full, plus the export-specific controls in Section 9 (role-gating, server-side assembly, audit-logging, and no shared-cache storage of the artifact).

On singling-out. The parties acknowledge that a cell-count minimum alone does not prevent singling-out of a rare attribute combination. The export’s defensibility therefore rests on its data shape rather than on a cell count: a token-only key with no quasi-identifiers beyond Customer’s own cohort tags; Coarsened Attributes so that a unique raw timing or watch value cannot fingerprint a recipient; and the contractual no-re-identification obligations in Section 6. Because the export carries per-recipient facts rather than computed rates, SweetNote’s n ≥ 25 reporting floor — which governs the reliability of a published rate — is not the control here; coarsening is.

6. No re-identification

SweetNote will not attempt to re-identify any recipient from the Recipient-Level Export beyond the single logged data-subject-rights path described in Section 11, and the export alone does not contain the token-to-identity mapping that would make such re-identification possible.

Customer represents, warrants, and covenants that, with respect to the re-joined recipient-level data on Customer’s side: (a) Customer will process it as personal data under Customer’s own privacy program and applicable law; (b) Customer will not combine it with any third party’s data, or apply any technique, for the purpose of re-identifying or singling out any recipient beyond Customer’s own existing relationship with that recipient; (c) Customer will impose equivalent no-re-identification and confidentiality obligations on any of Customer’s processors that receive the data; and (d) Customer’s recipient-facing privacy disclosures cover the analysis of the recipient’s engagement with Customer’s SweetNote campaign.

7. Lawful basis and recipient disclosure

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; analyzing a recipient’s engagement with a communication Customer itself sent is within the relationship Customer already has with the recipient.

Recipient consent to SweetNote’s capture of the engagement signal is governed by the existing reveal-page consent infrastructure described in the privacy notice §5. The SweetNote privacy notice discloses, in its description of engagement events, that where the sending organization has opted in and executed this Schedule, per-recipient engagement — including the reaction — may be provided to that organization keyed by a pseudonymous code it joins to its own records. Customer attests that any further recipient-facing disclosure required by Customer’s own privacy notice or applicable law is Customer’s responsibility and is delivered through Customer’s own channels.

8. Retention and deletion

The Recipient-Level Export carries pseudonymous personal data and therefore lives under the Personal Data retention canon in DPA §13, not the 24-month aggregate window. Specifically:

• The export is generatable from the close of the campaign’s engagement window through the thirty (30) day post-close Personal Data retention window. After that window, SweetNote purges the per-recipient data (including the Cohort Pass-Through), and the export can no longer be assembled; a later request returns an error indicating the retention window has closed.
• This Schedule introduces no new retention window. The per-recipient data’s lifetime is the standard 30-day-post-close PII horizon already committed in DPA §13.
• Customer is expected to download the export within the Retention Window. Once downloaded, Customer is the Controller of its own copy, and Customer’s retention schedule governs that copy on Customer’s systems.
• SweetNote does not retain a copy of the generated export file beyond the generation transaction; each export is assembled on request from data that itself sits under the 30-day-post-close horizon.

Recipient pseudonymization / opt-out request. If a recipient invokes the pseudonymization right described in DPA Section 10, or Customer routes SweetNote an opt-out concerning a recipient, SweetNote severs that recipient’s engagement data within the DPA Section 10 service level: the recipient’s stored identifiers and variation assignment are nulled, their engagement events are deleted, and their QR code stops resolving, so no further engagement can be attributed to them. A row for that recipient may still appear in a subsequently-generated export, carrying no variation assignment and no engagement facts — every behavioral value reads as not-observed.

9. Security measures

The technical and organizational measures described in DPA Section 7 apply in full. In addition, the Recipient-Level Export is subject to the following specific controls:

• Role-gated. Only an authenticated Customer user with the owner or admin role for the campaign’s workspace can request the export. The analyst and developer roles cannot generate it.
• Server-side assembly only. Per-recipient rows are assembled exclusively by a server-side function with the appropriate scope. No bulk per-recipient row set is ever assembled in the browser.
• Identifier exclusion at the source query. The assembly selects only the Recipient Token, the Behavioral Engagement Facts, and the Customer-supplied Cohort Pass-Through; direct identifiers and re-identification keys are not read into the export path.
• Audit-logged. Every generation writes an audit-log record (requester, campaign, row count, and the cohort columns included), retained per the audit-log schedule in DPA Section 13.
• Transport and caching. The export is transmitted over TLS 1.2 or higher and is marked no-store, so it is never cached at a shared or content-delivery layer.

10. Customer obligations

Customer assumes the following responsibilities specific to the Recipient-Level Export:

• Custody of the token mapping. Customer holds, and is responsible for securing, the mapping from the Recipient Token to recipient identity. The export alone does not contain this mapping.
• Controller-side handling. Customer processes the re-joined recipient-level data as personal data under Customer’s own privacy program, including access controls, retention, breach response, and data-subject-rights fulfillment on Customer’s systems.
• No re-identification beyond the existing relationship. Customer honors the no-re-identification covenant in Section 6.
• Privacy-notice disclosure. Customer is responsible for any recipient-facing disclosure that Customer’s privacy policy or applicable law requires concerning Customer’s analysis of recipient-level engagement data.
• Role administration. Customer administers the owner / admin role assignments in its workspace and is responsible for which of its users can generate the export.

11. Data subject rights

The DPA Section 10 obligations apply to the data subjects of the Recipient-Level Export without modification. SweetNote will assist Customer in responding to a Data Subject request (access, deletion, pseudonymization) by deleting the recipient’s engagement events and nulling their stored identifiers and variation assignment, so that any later export carries that recipient’s row with no variation assignment and no engagement facts (every behavioral value reads as not-observed), and by confirming the categories of data the export contains. Because the export carries no direct identifier, a Data Subject request that reaches SweetNote is fulfilled with respect to SweetNote’s systems by that deletion; the re-joined copy on Customer’s side is fulfilled by Customer as Controller of that copy.

12. Subprocessors

SweetNote engages the same subprocessors for the Recipient-Level Export that it engages for the base SweetNote service. The current SweetNote subprocessor list is published at thesweetnote.com/legal/subprocessors. The Recipient-Level Export does not introduce SweetNote-side subprocessors beyond those already disclosed there. If SweetNote engages a new subprocessor that handles the data covered by this Schedule, SweetNote will provide at least 30 days’ prior written notice in accordance with DPA Section 8.

13. Security incident response

The 72-hour notification commitment in DPA Section 11 applies in full to any Security Incident affecting the data covered by this Schedule. Because the export carries no direct identifier and does not contain the token-to-identity mapping, the practical exposure surface of an incident involving the export is narrower than for the underlying recipient PII: the worst-case exposure is pseudonymous data useful only in combination with Customer’s own records. SweetNote’s incident notification will characterize the affected data types and exposure surface accordingly.

14. Audit rights

Customer’s audit rights under DPA Section 12 extend to the Recipient-Level Export infrastructure. Most audit requests will be satisfied by SweetNote providing documentation of the server-side assembly and identifier-exclusion controls (available under NDA on request), sample audit-log records demonstrating that generations are logged, and responses to Customer’s information-security questionnaire (SIG, CAIQ, custom) covering the export-specific controls.

15. Termination

This Schedule terminates automatically when Customer disables the recipient-level export on all of Customer’s campaigns. Customer may disable the recipient-level export on a per-campaign basis at any time from the SweetNote portal; disabling it stops further export generation for that campaign. This Schedule may also be terminated at any time by either party on 30 days’ written notice. Termination does not affect any export file Customer has already downloaded, which Customer continues to control as described in Section 8.

16. 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 the 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. 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.

17. 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 Customer has the recipient-level export enabled on any campaign. Sections 5 (Pseudonymisation and singling-out controls), 6 (No re-identification), 8 (Retention and deletion), and 9 (Security measures) 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.

18. 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.

19. 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)
Recipient-level export support: support@thesweetnote.com

20. Execution

This Schedule is executed by both parties alongside the underlying MSA and DPA, by in-portal clickwrap acceptance at scoping (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 recipient-level export is generated; no export is possible until this Schedule is in force. This Schedule is offered as published, same paper for every brand, and is not redlined.

How this fits the rest of the SweetNote paper. This Schedule extends the DPA to cover the additional data flow that the recipient-level export creates: the return of Customer’s own engagement data to Customer in a pseudonymous, row-level grain. 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). It does not change SweetNote’s aggregate-only output everywhere else — SweetNote’s own dashboards, deliverable reports, and the cross-tenant benchmark remain aggregate, sample-floored, and never name-attached.