Azure Synapse Analytics

Datafly Signal writes events directly into a Synapse dedicated SQL pool table over the SQL Server wire protocol, so you can analyse first-party behaviour with the rest of your Azure data estate.

Why route Azure Synapse through Datafly Signal

• The data lands in infrastructure you own. Signal writes to your Azure Synapse directly from your own deployment. Datafly operates no intermediary and never holds a copy of your event data.
• Client IP and user agent are recorded as event context. Both come from the original visitor request rather than from your server, so geography and device analysis done in the warehouse reflects the actual visitor.
• Presets for eight verticals. General (the default: page, identify and the key cross-vertical events), Retail, Insurance, Travel, Media & Streaming, Publishing, B2B / SaaS and Automotive, each writing one named field per documented event property. Email, phone and names are written only as SHA-256 digests unless you deliberately change the installed blueprint.
• One consent decision governs every destination. Azure Synapse is gated by the same consent state as the rest of your stack, so a withdrawal applies everywhere at once.

Prerequisites

Before configuring Azure Synapse Analytics in Signal, you need an Azure account with a Synapse workspace, a dedicated SQL pool, and a target table.

CREATE TABLE dbo.signal_events (
    message_id      NVARCHAR(128)  NOT NULL,
    event_type      NVARCHAR(32)   NOT NULL,
    event_name      NVARCHAR(256)  NOT NULL,
    anonymous_id    NVARCHAR(256)  NOT NULL,
    user_id         NVARCHAR(256)  NULL,
    ip_address      NVARCHAR(64)   NULL,
    user_agent      NVARCHAR(1024) NULL,
    page_url        NVARCHAR(4000) NULL,
    page_path       NVARCHAR(2000) NULL,
    page_referrer   NVARCHAR(4000) NULL,
    org_id          NVARCHAR(64)   NULL,
    pipeline_id     NVARCHAR(64)   NULL,
    event_timestamp DATETIME2      NULL,
    received_at     DATETIME2      NULL,
    properties_json NVARCHAR(MAX)  NULL,
    context_json    NVARCHAR(MAX)  NULL
)
WITH (
    DISTRIBUTION = ROUND_ROBIN,
    HEAP
);

Configuration

Signal Setup

Quick Setup

1. Navigate to Integrations in the sidebar.
2. Open the Integration Library tab.
3. Find Azure Synapse Analytics or filter by Warehouse.
4. Click Install, select a variant if available, and fill in the required fields.
5. Click Install Integration to create the integration with a ready-to-use default blueprint.

API Setup

curl -X POST http://localhost:8084/v1/admin/integration-catalog/azure_synapse/install \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Azure Synapse Analytics",
    "variant": "default",
    "config": {
      "server": "datafly-synapse.sql.azuresynapse.net",
      "port": "1433",
      "database": "datafly_pool",
      "schema_name": "dbo",
      "table_name": "events",
      "username": "sqladmin",
      "password": "YOUR_PASSWORD",
      "encrypt": "true"
    },
    "delivery_mode": "server_side"
  }'

What Signal writes

Each event is one row, written with a single parameterised statement that skips a message_id already in the table, so a retried delivery does not create a duplicate row:

IF NOT EXISTS (SELECT 1 FROM [dbo].[signal_events] WHERE message_id = @p1)
INSERT INTO [dbo].[signal_events] ([message_id], [event_type], [event_name], [anonymous_id], [user_id], [ip_address], [user_agent], [page_url], [page_path], [page_referrer], [org_id], [pipeline_id], [event_timestamp], [received_at], [properties_json], [context_json])
VALUES (@p1, ..., @p16)

Query the JSON columns with JSON_VALUE, for example JSON_VALUE(properties_json, '$.transaction_id') or JSON_VALUE(properties_json, '$."@root".email_sha256').

Stored event context

Alongside the fields your blueprint maps (where email, phone, names and address are stored as normalised SHA-256 by default), each row carries the event’s collected context exactly as Signal received it. The blueprint does not filter or hash the context: this is deliberate (decision 2026-09-23), so the context is complete for attribution, fraud and debugging queries, and it is listed here so you can decide what to keep.

They are written to the ip_address, user_agent, page_url, page_path and page_referrer columns and, in full, to the context_json column, beside anonymous_id and user_id. Click and collected IDs outside the context are stored only where the blueprint maps them.

The IP address, device and advertising IDs, and cookie and click identifiers are personal data under UK and EU GDPR. To keep any of them out of storage, strip, mask or hash the field for every integration with the organisation data layer, apply URL redaction to page URLs, or remove it in the installed blueprint; and set the storage’s retention to match your privacy notice. See Personal data by integration.

Consent

The integration’s consent category in Signal decides which events reach Azure Synapse; events that fail it are never written. Every row also carries the visitor’s consent state (context.consent / context_json, and consent_analytics / consent_marketing in @root) so downstream queries can apply their own rules.

Testing

1. Enable the integration in Signal and trigger a test event on your website.
2. Open Synapse Studio and navigate to the dedicated SQL pool.
3. Run a query to check for events:

SELECT TOP 10 * FROM dbo.events ORDER BY timestamp DESC;

4. Verify that event rows are appearing with correct data.
5. In Signal, check the Live Events view to confirm delivery status shows as successful.

Troubleshooting

See also

• Data Warehouses overview
• Azure SQL
• Azure Data Explorer
• Azure Blob Storage