Release Status Released Supported By Singer community
Availability Free Status Page Amplitude Status Page
Default Historical Sync n/a Default Replication Frequency 30 minutes
Whitelisting Tables and columns Destination Incompatibilities None

Connecting Amplitude

Amplitude Setup requirements

To set up Amplitude in Stitch, you need:

  • To be on an Amplitude Enterprise or Growth plan. Amplitude requires this to access the Query product add-on.

  • To have purchased the Amplitude Query product add-on. Query is an Amplitude-managed Snowflake database, which Stitch’s integration replicates data from.

Step 1: Retrieve your Snowflake credentials

Stitch’s Amplitude integration connects to your Amplitude-managed Snowflake database to replicate data.

To connect Stitch to Amplitude, you’ll need to retrieve your Snowflake credentials from Amplitude. Reach out to Amplitude support or your Amplitude Success Manager to get your credentials.

When you receive your credentials, you can move onto the next step.

Step 2: Add Amplitude as a Stitch data source

  1. Sign into your Stitch account.
  2. On the Stitch Dashboard page, click the Add Integration button.

  3. Click the Amplitude icon.

  4. Enter a name for the integration. This is the name that will display on the Stitch Dashboard for the integration; it’ll also be used to create the schema in your destination.

    For example, the name “Stitch Amplitude” would create a schema called stitch_amplitude in the destination. Note: Schema names cannot be changed after you save the integration.

  5. In the Amplitude Snowflake Username field, enter your Snowflake username.
  6. In the Amplitude Snowflake Password field, enter the Snowflake user’s password.
  7. In the Amplitude Snowflake Account field, enter the Snowflake account.
  8. In the Amplitude Snowflake Warehouse field, enter the name of the Snowflake warehouse.
  9. In the Amplitude Snowflake Database field, enter the name of the Snowflake database.

Step 3: Create a replication schedule

In the Replication Frequency section, you’ll create the integration’s replication schedule. An integration’s replication schedule determines how often Stitch runs a replication job, and the time that job begins.

Stitch offers two methods of creating a replication schedule:

  • Replication Frequency: This method requires selecting the interval you want replication to run for the integration. Start times of replication jobs are based on the start time and duration of the previous job. Refer to the Replication Frequency documentation for more information and examples.
  • Anchor scheduling: Based on the Replication Frequency, or interval, you select, this method “anchors” the start times of this integration’s replication jobs to a time you select to create a predictable schedule. Anchor scheduling is a combination of the Anchor Time and Replication Frequency settings, which must both be defined to use this method. Additionally, note that:

    • A Replication Frequency of at least one hour is required to use anchor scheduling.
    • An initial replication job may not begin immediately after saving the integration, depending on the selected Replication Frequency and Anchor Time. Refer to the Anchor Scheduling documentation for more information.

To help prevent overages, consider setting the integration to replicate less frequently. See the Understanding and Reducing Your Row Usage guide for tips on reducing your usage.

Initial and historical replication jobs

After you finish setting up Amplitude, its Sync Status may show as Pending on either the Stitch Dashboard or in the Integration Details page.

For a new integration, a Pending status indicates that Stitch is in the process of scheduling the initial replication job for the integration. This may take some time to complete.

Free historical data loads

The first seven days of replication, beginning when data is first replicated, are free. Rows replicated from the new integration during this time won’t count towards your quota. Stitch offers this as a way of testing new integrations, measuring usage, and ensuring historical data volumes don’t quickly consume your quota.


Amplitude table schemas

Stitch’s Amplitude replicates two types of tables: Events and merged user IDs.

For each project in your Amplitude account, a set of these tables will be available for replication. Stitch will append a project’s ID to each table name to make them easily identifiable. For example: If a project has an ID of 168342, the events table for the project will be named events_168432.

You can identify which tables are for a specific project by comparing the ID in the table name to the projects in your Amplitude account. You can access this page in your Amplitude account by clicking the User menu (top right corner) > Settings > Projects.

Highlighted project ID field in the Amplitude UI


events_[project_id]

Replication Method: Key-based Incremental Replication Key : event_time
Primary Key : uuid Documentation: Official Docs

events_[project_id] tables contain info about the events logged in your Amplitude projects.

Note: Each event table will have the project ID appended. For example: If a project has an ID of 168342, the events table for the project will be named events_168432.

uuid
STRING

The unique event ID.

event_time
DATE-TIME

The timestamp, which is the client_event_time adjusted by the difference between server_received_time and client_upload_time.

Amplitude calculates this as:

event_time = client_event_time + (server_received_time - client_upload_time)

This is used in Amplitude to organize events in charts.

adid
STRING

The Android/Google Play Services advertising ID.

amplitude_event_type
STRING

This is a legacy field. Use event_type instead.

amplitude_id
NUMBER

An internal Amplitude ID used to count unique users. For example: 1234567890

app
NUMBER

The project ID found in your project’s Amplitude Settings page.

city
STRING

The city where the event took place.

client_event_time
DATE-TIME

The timestamp of when the device logged the event.

client_upload_time
DATE-TIME

The timestamp of when the device uploaded the event.

country
STRING

The country where the event took place.

data
STRING

Dictionary where certain fields such as first_event and merged_amplitude_id are stored.

Depending on the destination you’re using, you can use that destination’s available JSON functions to parse the data in this column. Click the links below to view that destination’s JSON function documentation:

device_brand
STRING

The brand of device used in the event. For example: Apple

device_carrier
STRING

The mobile carrier of the device used in the event. For example: Verizon

device_family
STRING

The family of the device used in the event. For example: Apple iPhone

device_id
STRING

The specific device identifier.

device_manufacturer
STRING

The manufacturer of the device used in the event. For example: Apple

device_model
STRING

The model of the device used in the event. For example: iPad mini

device_type
STRING

The type of the device used in the event. For example: Apple iPhone 5s

dma
STRING

The designated marketing area (DMA). For example: `San Francisco-Oakland-San Jose, CA

event_id
NUMBER

A counter that distinguishes events.

event_properties
STRING

Details about the event.

Depending on the destination you’re using, you can use that destination’s available JSON functions to parse the data in this column. Click the links below to view that destination’s JSON function documentation:

event_type
STRING

The assigned type of the event. For example: Add Friend

followed_an_identity
BOOLEAN

If true, there was an identify event between this SDK event and the last SDK event seen.

groups
STRING

Details about the groups associated with the event. Refer to Amplitude’s documentation for more info.

Depending on the destination you’re using, you can use that destination’s available JSON functions to parse the data in this column. Click the links below to view that destination’s JSON function documentation:

idfa
STRING

The iOS ID for Advertiser.

ip_address
STRING

The IP address.

location_lat
NUMBER

The latitude.

location_lng
NUMBER

The longitude.

os_name
STRING

The name of the OS used in the event. For example: ios

os_version
STRING

The version of the OS used in the event. For example: 1.0

paying
STRING

If true, the user has logged revenue at some point. The value will be (none) otherwise.

region
STRING

The region where the event took place.

server_upload_time
DATE-TIME

The timestamp of when the Amplitude servers received the event.

session_id
NUMBER

The session start time, in milliseconds since epoch.

start_version
STRING

The app version the user was first tracked on.

user_creation_time
DATE-TIME

The timestamp of the user’s first event.

user_id
STRING

An ID for the user, specified by you.

user_properties
STRING

Details about the user associated with the event.

Depending on the destination you’re using, you can use that destination’s available JSON functions to parse the data in this column. Click the links below to view that destination’s JSON function documentation:

version_name
STRING

The app version.


merge_ids_[project_id]

Replication Method: Key-based Incremental Replication Key : merge_event_time
Primary Key : amplitude_id : merge_server_time : merged_amplitude_id : merge_event_time Documentation: Official Docs

merge_ids_[project_id] tables contain info about merged users. These are users whose records have been merged with other user records to eliminate duplicates.

For example: If an anonymous user logs events anonymously before signing in, they will go from being anonymous to a recognized user. Without merging the user’s records, it’ll look like two users with two sets of events, rather than one user completing a series of events.

For more info on how Amplitude handles merging users, refer to their documentation.

Note: Each table will have the project ID appended. For example: If a project has an ID of 168342, the merged ID table for the project will be named merge_ids_168432.

amplitude_id
NUMBER

The Amplitude being merged into a user’s original Amplitude ID.

merge_server_time
DATE-TIME

The server time when the user’s new Amplitude was associated with their original Amplitude ID.

merged_amplitude_id
NUMBER

The originally assigned Amplitude ID when the user was first created.

merge_event_time
DATE-TIME

The time when the user’s new Amplitude ID was associated with their original Amplitude ID.



Questions? Feedback?

Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.