Data Flow & Processing Description

Version 1.0

Last Updated: July 19, 2026

Purpose

This document describes how Merchant Customer Data flows through the SetRoasFlow platform.

Its purpose is to provide Merchants, privacy professionals, security reviewers and technical teams with a transparent overview of how information is collected, processed, stored and routed.

This document is descriptive only and should be read together with the Privacy Policy, Terms of Service and Data Processing Addendum.

High-Level Processing Pipeline

The processing lifecycle generally follows the sequence below.

Connected Property
        │
        ▼
Collection Method
(SmartScript / Plugin / API / SDK)

        │
        ▼
Cloudflare Edge

        │
        ├── Request Validation
        ├── Consent Evaluation
        ├── Event Validation
        ├── Identity Resolution
        ├── Hash Processing
        ├── Customer Profile Update
        ├── Audience Evaluation
        ├── Destination Routing
        └── Warehouse Export Buffer

        │
        ▼
Platform Storage

        │
        ├──────────────► Merchant-selected Destinations
        │                (real time, per event)
        │
        └──────────────► Merchant-operated Data Infrastructure
                         (batched, from the export buffer)

The exact workflow depends on the Collection Method and Merchant configuration.

Connected Properties

A Connected Property is any digital property owned or controlled by the Merchant that transmits information to SetRoasFlow.

Examples include:

• ecommerce stores;
• marketing websites;
• landing pages;
• web applications;
• mobile applications;
• custom integrations.

Each Connected Property remains under the Merchant's control.

Collection Methods

SetRoasFlow supports multiple methods for collecting information.

Examples include:

• SmartScript;
• Shopify integrations;
• WooCommerce integrations;
• APIs;
• SDKs;
• server-side integrations;
• webhook-based integrations.

Additional Collection Methods may be introduced over time.

Event Collection

Supported Collection Methods transmit events generated by visitors interacting with a Connected Property.

Examples may include:

• page views;
• product views;
• searches;
• add-to-cart events;
• checkout events;
• purchases;
• custom events defined by the Merchant.

SetRoasFlow processes only the information provided by the configured Collection Method.

Edge Processing

Incoming requests are processed through cloud edge infrastructure before reaching downstream platform components.

Edge processing enables:

• request validation;
• early filtering;
• consent evaluation;
• normalization;
• routing decisions;
• lower latency.

Processing at the edge reduces unnecessary downstream processing.

Request Validation

Before an event enters the processing pipeline, SetRoasFlow performs validation designed to reject malformed or incomplete requests.

Validation may include:

• payload structure;
• supported event types;
• authentication information where applicable;
• integration configuration;
• request integrity.

Invalid requests may be rejected before additional processing occurs.

Consent Evaluation

Where supported by the configured integration, privacy preferences are evaluated before downstream processing.

Depending on Merchant configuration, this may result in:

• normal processing;
• restricted processing;
• identifier suppression;
• destination suppression;
• event rejection.

Consent handling is driven by Merchant configuration.

Event Normalization

Different Collection Methods may provide information in different formats.

Normalization converts supported events into a consistent internal structure to enable:

• profile updates;
• routing;
• reporting;
• destination compatibility.

Normalization does not expand the scope of information collected.

Identity Resolution

Identity Resolution associates multiple events belonging to the same individual where supported identifiers are available.

Depending on available information, identifiers may include:

• email addresses;
• phone numbers;
• browser identifiers;
• customer identifiers;
• platform-generated identifiers.

Identity Resolution improves continuity of Customer Profiles while avoiding unnecessary duplication.

Customer Profile Processing

Following Identity Resolution, supported information may be associated with an existing Customer Profile or used to create a new profile.

Profiles may include:

• identifiers;
• events;
• purchases;
• behavioral history;
• calculated attributes;
• audience membership.

Customer Profiles remain associated with the Merchant that collected the information.

Audience Evaluation

After profile updates, SetRoasFlow may evaluate whether a Customer Profile belongs to one or more Merchant-defined audiences.

Audience membership is determined according to Merchant configuration.

SetRoasFlow does not independently define marketing audiences.

Hash Processing

Where configured Destinations support hashed identifiers, supported fields may be transformed using SHA-256 prior to transmission.

Hashing occurs only where compatible with the configured workflow.

Hashing reduces exposure of raw identifiers during outbound processing.

Destination Routing

Following successful processing, information may be transmitted to Destinations selected by the Merchant.

Examples include:

• advertising platforms;
• analytics platforms;
• marketing automation platforms;
• customer engagement platforms;
• customer relationship management platforms;
• data warehouses, object storage and HTTP endpoints operated by the Merchant.

Only Destinations explicitly configured by the Merchant receive transmitted information.

The form of the data differs by category. Advertising and analytics platforms receive hashed identifiers only. Marketing and customer relationship management platforms receive email addresses and telephone numbers in clear text, and only where consent permits. See the Privacy Architecture document for the complete table.

Warehouse Export

Where a Merchant enables warehouse export, each processed event is additionally written to a queue held on Cloudflare infrastructure and delivered in batches to data infrastructure operated by the Merchant.

Characteristics of this stage:

• the queue is operational, not archival: records are deleted three days after delivery;
• delivery is retried on transient failures; records that cannot be delivered after repeated attempts are retained for the same period and then deleted;
• exported records follow a stable, versioned schema and include the consent decision applying to each event;
• personal data is excluded unless the Merchant explicitly enables it, and is never exported where consent is absent or a United States opt-out signal applies;
• network identifiers (IP address and user agent) are not exported.

Events processed in test mode are never queued for export.

Platform Storage

Information may be stored for purposes including:

• Customer Profiles;
• Merchant configuration;
• routing state;
• operational processing;
• reporting;
• platform functionality.

Storage periods are governed by the Data Retention Policy and Merchant instructions where applicable.

Operational Logging

Operational logs support:

• troubleshooting;
• platform monitoring;
• incident investigation;
• service reliability.

Logging is limited to information reasonably necessary for operational purposes.

Error Handling

Where processing cannot be completed successfully, SetRoasFlow may:

• reject the request;
• retry supported operations;
• log operational failures;
• notify the Merchant where appropriate.

Error handling is designed to prevent partial or inconsistent processing.

Security Controls Throughout the Pipeline

Security controls are applied throughout processing and may include:

• encrypted communications;
• authenticated requests;
• authorization checks;
• infrastructure isolation;
• least-privilege access;
• secure secret management;
• operational monitoring.

Additional controls are described in the Security Overview.

Merchant Control

The Merchant controls:

• Connected Properties;
• Collection Methods;
• configured Destinations;
• data submitted for processing;
• consent configuration;
• customer communications.

SetRoasFlow processes Merchant Customer Data only to provide the Services requested by the Merchant.

Continuous Evolution

The processing pipeline may evolve as new Collection Methods, infrastructure improvements and platform capabilities are introduced.

Material architectural changes will be reflected in updated documentation where appropriate.

Related Documentation

This document should be read together with:

• Privacy Policy
• Data Processing Addendum
• Security Overview
• Privacy Architecture
• Data Retention Policy
• Subprocessors List

Contact

Questions regarding this document may be directed to:

Operator

Matteo De Giuseppe

Italy

Email

[email protected]

Version History

End of Data Flow & Processing Description