Customer.io

Microsoft Azure Blob Storage (advanced)

Premium This feature is available for Premium plans. Enterprise This feature is available for Enterprise plans.

How it works

This integration sends CSV, JSON, or parquet files containing your data to your MS Azure Blob Storage (advanced) bucket. Then you can ingest the files in your storage bucket to your data warehouse of choice.

We write files for each type of incoming call to your storage bucket every 10 minutes. So you'll have files for identify calls, track calls, and so on. Files are named with an incrementing number, so it's easy to determine the sequence of files, and the order of incoming calls.

sequenceDiagram participant a as Customer.io participant b as Storage Bucket participant c as MS Azure Blob Storage (advanced) loop every 10 minutes a->>b: export CSV, JSON, or parquet files b->>c: ingest c->>b: expire/delete files<br>before next sync end

Sync frequency and file names

Syncs occur every 10 minutes. Each sync file contains data from the previous sync interval. For example, if the last sync occurred at 12:00 PM, the next sync will only send data from 12:00 PM to 12:09:59 PM.

Each sync generates new files for each data type in your storage bucket. Files are named in the format <integration id>.<integration action id>.<current position>.<type>.

  • The integration ID and action ID are unique identifiers generated by Customer.io. You’ll see them with the first sync.
  • current position is an incrementing number beginning at 1 that indicates the order of syncs. So your first sync is 1, the next one is 2, etc.
  • type is the type of incoming call—identify, track, page, screen, alias, or group.

So, if your file is called 2184.13699.1.track.json, it’s the first sync file for the track call type.

Getting started

  1. Go to Data & Integrations > Integrations and select MS Azure Blob Storage (advanced) in the Directory tab.
  2. Connect to your storage bucket:
    1. Output Format: Format of the data files that will be created.
    2. Blob SAS URL: The SAS URL of the Azure Blob Storage container with permissions to upload files to a container. Learn how to generate an Azure SAS URL [in our documentation](https://docs.customer.io/journeys/ms-azure-data-out/).
    3. Blob Path: Optional folder inside the container where files will be written to.
  3. Review your setup and click Finish to enable your integration.

Schemas

The following schemas represent JSON for the different types of files we export to your storage bucket (identify, track, and so on). For CSV and Parquet files, we stringify objects and arrays. For example, if identify calls contain the traits object with a first_name and last_name, CSV files output to your storage bucket will contain a traits column with data that looks like this for each row: "{ "\first_name\": \"Bugs\", \"last_name\": \"Bunny\" }".

Identifies files contain identify calls sent to Customer.io. The context and traits in the schema below are objects in JSON. In CSV and parquet files, these columns contain stringified objects.

  • idstring
    A unique identifier for a Data Pipelines event, ensuring that each individual event is unique.
  • received_atinteger
    The Unix timestamp (in seconds) when Data Pipelines receives an event.
  • sent_atinteger
    The Unix timestamp (in seconds) when a library sends an event to Data Pipelines.
  • anonymous_idstring
    A unique substitute for a User ID in cases when you don’t have an absolutely unique identifier. Our libraries generate this value automatically to help you track people before they sign up, log in, provide their email, etc.
  • user_idstring
    The unique identifier for a person. This value should be unique across systems, so you recognize the same person in your sources _and_ destinations.
  • Additional properties that you know about a person. We've listed some common/reserved traits below, but you can add any traits that you might use in another system.
  • A dictionary of context about a source call/event, like the user’s IP address or locale. Context is automatically collected by our source libraries.

Groups files contain group calls sent to Customer.io. If your integration outputs CSV or parquet files, the context and traits columns contain stringified objects.

  • idstring
    A unique identifier for a Data Pipelines event, ensuring that each individual event is unique.
  • received_atinteger
    The Unix timestamp (in seconds) when Data Pipelines receives an event.
  • sent_atinteger
    The Unix timestamp (in seconds) when a library sends an event to Data Pipelines.
  • anonymous_idstring
    A unique substitute for a User ID in cases when you don’t have an absolutely unique identifier. Our libraries generate this value automatically to help you track people before they sign up, log in, provide their email, etc.
  • user_idstring
    The unique identifier for a person. This value should be unique across systems, so you recognize the same person in your sources _and_ destinations.
  • group_idstring
    ID of the group
  • objectTypeIdstring
    If you use Customer.io Journeys as a destination, this value is the type of group/object your group belongs to; object type IDs are stringified integers. If you don't include this value, we assume the object type ID is 1. See objects in Customer.io Journeys for more information.
  • Additional data points that the call assigns to the group.

Tracks contains entries for the track calls you send to Customer.io. It shows information about the events your users perform.

If your integration outputs CSV or parquet files, the context and properties columns contain stringified objects. If your integration outputs JSON files, the context and properties columns contain objects.

  • idstring
    A unique identifier for a Data Pipelines event, ensuring that each individual event is unique.
  • received_atinteger
    The Unix timestamp (in seconds) when Data Pipelines receives an event.
  • sent_atinteger
    The Unix timestamp (in seconds) when a library sends an event to Data Pipelines.
  • anonymous_idstring
    A unique substitute for a User ID in cases when you don’t have an absolutely unique identifier. Our libraries generate this value automatically to help you track people before they sign up, log in, provide their email, etc.
  • user_idstring
    The unique identifier for a person. This value should be unique across systems, so you recognize the same person in your sources _and_ destinations.
  • eventstring
    The slug of the event name, mapping to an event-specific table.
  • event_textstring
    The name of the event.
  • Additional properties sent with the page call. We've listed some common/reserved traits captured by our Analytics.js library, but you can add any properties that you might use in another system.
  • A dictionary of context about a source call/event, like the user’s IP address or locale. Context is automatically collected by our source libraries.

Pages contains entries for the page calls sent to Customer.io. If your integration outputs CSV or parquet files, the context and properties columns contain stringified objects. If your integration outputs JSON files, the context and properties columns contain objects.

  • idstring
    A unique identifier for a Data Pipelines event, ensuring that each individual event is unique.
  • received_atinteger
    The Unix timestamp (in seconds) when Data Pipelines receives an event.
  • sent_atinteger
    The Unix timestamp (in seconds) when a library sends an event to Data Pipelines.
  • anonymous_idstring
    A unique substitute for a User ID in cases when you don’t have an absolutely unique identifier. Our libraries generate this value automatically to help you track people before they sign up, log in, provide their email, etc.
  • user_idstring
    The unique identifier for a person. This value should be unique across systems, so you recognize the same person in your sources _and_ destinations.
  • Additional properties sent with the page call. We've listed some common/reserved traits captured by our Analytics.js library, but you can add any properties that you might use in another system.
  • A dictionary of context about a source call/event, like the user’s IP address or locale. Context is automatically collected by our source libraries.

Screens files contain entries for the screen calls sent to Customer.io. If your integration outputs CSV or parquet files, the context and properties columns contain stringified objects. If your integration outputs JSON files, the context and properties columns contain objects.

  • idstring
    A unique identifier for a Data Pipelines event, ensuring that each individual event is unique.
  • received_atinteger
    The Unix timestamp (in seconds) when Data Pipelines receives an event.
  • sent_atinteger
    The Unix timestamp (in seconds) when a library sends an event to Data Pipelines.
  • anonymous_idstring
    A unique substitute for a User ID in cases when you don’t have an absolutely unique identifier. Our libraries generate this value automatically to help you track people before they sign up, log in, provide their email, etc.
  • user_idstring
    The unique identifier for a person. This value should be unique across systems, so you recognize the same person in your sources _and_ destinations.
  • Additional properties that you sent in your screen event
  • A dictionary of context about a source call/event, like the user’s IP address or locale. Context is automatically collected by our source libraries.

The Alias schema contains entries for the alias calls you send to Customer.io. It shows information about the users you merge, with each entry showing a user’s new user_id and their previous_id.

  • idstring
    A unique identifier for a Data Pipelines event, ensuring that each individual event is unique.
  • received_atinteger
    The Unix timestamp (in seconds) when Data Pipelines receives an event.
  • sent_atinteger
    The Unix timestamp (in seconds) when a library sends an event to Data Pipelines.
  • previous_idstring
    The anonymousId or userId value that you want to merge into the canonical profile.
  • user_idstring
    The unique identifier for a person. This value should be unique across systems, so you recognize the same person in your sources _and_ destinations.