This integration is powered by Singer's Amplitude tap. For support, visit the GitHub repo or join the Singer Slack.
Amplitude integration summary
Stitch’s Amplitude integration relies on the Amplitude Query product add-on, which utilizes a Snowflake database to store data.
Amplitude integrations can replicate event and merged user ID data. Refer to the Schema section for more info.
Amplitude feature snapshot
A high-level look at Stitch's Amplitude (v1) integration, including release status, useful links, and the features supported in Stitch.
| STITCH | |||
| Release status |
Released on August 29, 2018 |
Supported by | |
| Stitch plan |
Standard |
API availability |
Available |
| Singer GitHub repository | |||
| REPLICATION SETTINGS | |||
| Anchor Scheduling |
Supported |
Advanced Scheduling |
Supported |
| Table-level reset |
Unsupported |
Configurable Replication Methods |
Unsupported |
| DATA SELECTION | |||
| Table selection |
Supported |
Column selection |
Supported |
| Select all |
Supported |
||
| TRANSPARENCY | |||
| Extraction Logs |
Supported |
Loading Reports |
Supported |
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
- Sign into your Stitch account.
-
On the Stitch Dashboard page, click the Add Integration button.
-
Click the Amplitude icon.
-
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_amplitudein the destination. Note: Schema names cannot be changed after you save the integration. - In the Amplitude Snowflake Username field, enter your Snowflake username.
- In the Amplitude Snowflake Password field, enter the Snowflake user’s password.
- In the Amplitude Snowflake Account field, enter the Snowflake account.
- In the Amplitude Snowflake Warehouse field, enter the name of the Snowflake warehouse.
- 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.
Amplitude integrations support the following replication scheduling methods:
-
Advanced Scheduling using Cron (Advanced or Premium plans only)
To keep your row usage low, 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.
Initial replication jobs with Anchor Scheduling
If using Anchor Scheduling, an initial replication job may not kick off immediately. This depends on the selected Replication Frequency and Anchor Time. Refer to the Anchor Scheduling documentation for more information.
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 reference
Schemas and versioning
Schemas and naming conventions can change from version to version, so we recommend verifying your integration’s version before continuing.
The schema and info displayed below is for version 1 of this integration.
This is the latest version of the Amplitude integration.
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.
Table and column names in your destination
Depending on your destination, table and column names may not appear as they are outlined below.
For example: Object names are lowercased in Redshift (CusTomERs > customers), while case is maintained in PostgreSQL destinations (CusTomERs > CusTomERs). Refer to the Loading Guide for your destination for more info.
events
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.
|
Key-based Incremental |
|
|
Primary Key |
uuid |
|
Replication Key |
event_time |
| Useful links |
|
adid STRING |
|
amplitude_event_type STRING |
|
amplitude_id NUMBER |
|
app NUMBER |
|
city STRING |
|
client_event_time DATE-TIME |
|
client_upload_time DATE-TIME |
|
country STRING |
|
data STRING |
|
device_brand STRING |
|
device_carrier STRING |
|
device_family STRING |
|
device_id STRING |
|
device_manufacturer STRING |
|
device_model STRING |
|
device_type STRING |
|
dma STRING |
|
event_id NUMBER |
|
event_properties STRING |
|
event_time
DATE-TIME |
|
event_type STRING |
|
followed_an_identity BOOLEAN |
|
groups STRING |
|
idfa STRING |
|
ip_address STRING |
|
location_lat NUMBER |
|
location_lng NUMBER |
|
os_name STRING |
|
os_version STRING |
|
paying STRING |
|
region STRING |
|
server_upload_time DATE-TIME |
|
session_id NUMBER |
|
start_version STRING |
|
user_creation_time DATE-TIME |
|
user_id STRING |
|
user_properties STRING |
|
uuid
STRING |
|
version_name STRING |
merge_ids
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.
|
Key-based Incremental |
|
|
Primary Keys |
amplitude_id merge_server_time merged_amplitude_id merge_event_time |
|
Replication Key |
merge_event_time |
| Useful links |
|
amplitude_id
NUMBER |
|
merge_event_time
DATE-TIME |
|
merge_server_time
DATE-TIME |
|
merged_amplitude_id
NUMBER |
| Related | Troubleshooting |
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.