Azure Data Explorer

Datafly Signal writes events directly into an Azure Data Explorer (Kusto) table so you can query first-party behaviour using KQL.

Prerequisites

Before configuring Azure Data Explorer in Signal, you need an Azure account with an ADX cluster, a database and table, and an Azure AD app registration for authentication.

Create an Azure Account

If you don’t already have one, sign up at azure.microsoft.com.

Create an Azure Data Explorer Cluster

In the Azure portal, search for Azure Data Explorer Clusters and click Create.
Enter a Cluster name (e.g. datafly-adx).
Select a Region close to your Signal deployment.
Choose a Compute specification based on your expected data volume.
Click Review + Create > Create.
Once deployed, note the URI (e.g. https://datafly-adx.westeurope.kusto.windows.net).

Create a Database

Open your ADX cluster in the Azure portal.
Click Databases in the left sidebar.
Click Add database.
Enter a Database name (e.g. analytics).
Set the Retention period and Cache period as needed.
Click Create.

Create a Table

In the ADX cluster, go to Query in the left sidebar.
Select your database and run the following KQL command:

.create table Events (
  event_id: string,
  type: string,
  event: string,
  anonymous_id: string,
  user_id: string,
  timestamp: datetime,
  received_at: datetime,
  context: dynamic,
  properties: dynamic,
  traits: dynamic,
  source_id: string,
  integration_id: string
)

Optionally enable streaming ingestion on the table:

.alter table Events policy streamingingestion enable

Register an Azure AD Application

In the Azure portal, go to Azure Active Directory > App registrations > New registration.
Enter a name (e.g. datafly-signal-adx).
Click Register.
Note the Application (client) ID and Directory (tenant) ID from the overview page.

Create a Client Secret

On the app registration page, go to Certificates & secrets > Client secrets > New client secret.
Enter a description and expiry period.
Click Add.
Copy the secret value immediately — it is only shown once.

⚠️

Store the client secret securely. Set a calendar reminder to rotate it before expiry to avoid service interruptions.

Grant Database Permissions

In the ADX cluster, go to Databases > your database > Permissions.
Click Add > Ingestor.
Search for your Azure AD application name and select it.
Click Select.

Configuration

Field	Type	Required	Description
`endpoint`	string	Yes	The Azure Data Explorer cluster URL (e.g. `https://mycluster.westeurope.kusto.windows.net`). Also accepts `cluster_url`.
`database`	string	Yes	The target database name.
`table_name`	string	Yes	The target table name to ingest data into.
`ingestion_mapping`	string	No	Optional name of a pre-defined ingestion mapping.
`client_id`	string	Yes	The Azure AD application (client) ID.
`client_secret`	secret	Yes	The Azure AD application client secret.
`tenant_id`	string	Yes	The Azure AD tenant (directory) ID.

Signal Setup

Quick Setup

Navigate to Integrations in the sidebar.
Open the Integration Library tab.
Find Azure Data Explorer or filter by Warehouse.
Click Install, select a variant if available, and fill in the required fields.
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_data_explorer/install \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Azure Data Explorer",
    "variant": "default",
    "config": {
      "endpoint": "https://datafly-adx.westeurope.kusto.windows.net",
      "database": "analytics",
      "table_name": "Events",
      "client_id": "00000000-0000-0000-0000-000000000000",
      "client_secret": "YOUR_CLIENT_SECRET",
      "tenant_id": "00000000-0000-0000-0000-000000000000"
    },
    "delivery_mode": "server_side"
  }'

Schema

Signal writes the standard event envelope. The KQL table definition shown in Prerequisites uses:

Column	KQL type	Notes
`event_id`	`string`	Unique per event.
`type`	`string`	Event type.
`event`	`string`	Event name (snake_case).
`anonymous_id`	`string`	First-party visitor identifier.
`user_id`	`string`	Logged-in user identifier (nullable).
`timestamp`	`datetime`	Client event time.
`received_at`	`datetime`	Time Signal received the event.
`context`	`dynamic`	Page, device, user agent, consent metadata.
`properties`	`dynamic`	Custom event properties.
`traits`	`dynamic`	User traits.
`source_id`	`string`	Pipeline source identifier.
`integration_id`	`string`	Signal integration identifier.

Use dynamic columns with mv-expand, dot-notation, and the parse_json family for nested access.

ADX is a first-party destination under your control. The default blueprint forwards all events. Apply consent filtering via pipeline transforms or KQL functions over context.consent downstream if needed.

Testing

Enable the integration in Signal and trigger a test event on your website.
In the ADX cluster, go to Query and select your database.
Run a query to check for events:

Events
| order by timestamp desc
| take 10

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

Troubleshooting

Problem	Solution
Events not appearing in the table	Verify the cluster URL, database name, and table name are correct. Check that the table exists.
`Unauthorized`	The client ID, client secret, or tenant ID is incorrect. Verify the Azure AD app registration details.
`Forbidden`	The Azure AD app lacks Ingestor permission on the database. Add the permission in ADX Permissions.
Client secret expired	Generate a new client secret in Azure AD > App registrations > Certificates & secrets and update the Signal config.
Ingestion latency	By default, ADX batches ingestion. Enable streaming ingestion on the table for lower latency.
Schema mismatch	The event fields must match the table column names and types. Verify with `.show table Events schema`.

Visit Azure Data Explorer documentation for full KQL reference and ingestion management guides.