About Amp360

Amp360 merges behavioral, contextual, and transactional data into actionable profiles, even when your data sources are incomplete, inconsistent, or lack linking keys.

A user of Amp360 should be comfortable using SQL to build databases and tables, design queries, understand what is required to synchronize a dataset with external systems and workflows (both upstream and downstream), and how to leverage attributes available from within Amperity to help their organizations learn more about their customers.

The Customer 360 tab in Amperity.

Common workflows

The most common workflows for Amp360 focus on data and databases, writing SQL to define tables and enable workflows, and interacting with attributes (both those output by Stitch and those generated by how semantic tags are applied to your tenant). Use Amp360 to:

  • Build your customer 360

  • Use SQL to define multiple databases, custom databases, and custom tables

  • Extend your customer 360 to make use of vertical-specific attributes and to define your own custom attributes

  • Explore data using the Data Explorer

The SQL query editor enable workflows, such as:

  • Linking the Amperity ID (first-party) to third-party provider person IDs

  • Enriching third-party non-PII data for customer analysis, segmentation, and targeting

  • Standardizing data for certain PII details

  • Using data hygiene to verify accuracy of PII with third-party data providers

  • Linking unknown IDs to known customers

  • Mapping unknown users to known customers

  • Mapping anonymous users to known customers

Customer 360 database

The customer 360 database is the most important database you can build in Amperity. It is the source from which all queries and segments are created and from which data will be sent to external systems for downstream workflows.

Flexible merge rules

Some customer data platforms require using an inflexible merge rule across multiple fields, which results in lower quality data across your customer 360 profile. This problem is magnified when that inflexible merge rule must also be applied to multuple customer 360 databases.

Amperity combines the use of flexible merge rules with a patented system that allows multiple customer 360 databases to exist within the same tenant. This ensures that:

  1. Merge rules are 100% configurable

  2. Each field can have its own merge rule

  3. Each customer 360 database can have its own set of merge rules

  4. Each tenant can support a variety of merge rules to meet all of the requirements for any individual use case

For example, data sources from call centers, online transactions, and email platforms may contain slightly different sets of customer profile data.

Use flexible merge rules to support many customer 360 databases.

After loading this data to Amperity and assigning the Amperity ID to each of your customers, you can use flexible merge rules to support multiple customer 360 databases.

  • Your operations teams can combine prioritizing the most common values for each customer with deterministic matching

  • Your email marketing team can combine prioritizing customer profile values from your email platform with probabilistic matching

  • Your paid media team can combine all possible values to improve match rates on platforms like Google Ads and Facebook

Ask your Amperity implementation team for recommendations and best practices for how you can configure flexible merge rules to support all of your use cases.

Customer profiles

A customer profile is a collection of attributes that are associated with a single unique individual in the customer 360 database. The total number of customer profiles is equal to the total number of rows in the Customer 360 data table. This total correlates strongly, but not exactly, to the total number of Amperity IDs assigned to unique individuals in the same data set.

Customer profile details are pulled from the Customer_360 table, which represents each customer’s unified profile. This table contains common profile attributes, such as:

  • Names (first name, last name), email address, physical address, phone

  • Transaction details (first purchase, last purchase, total purchases, etc)

  • Other custom profile values that are unique to your company.

These details are summarized in the Customer Profile section of the Customer 360 tab.

Each customer profile is a collection of common attributes (first name, last name, email, phone, etc.), transaction attributes (first purchase, last purchase, total purchases, etc.), and other custom values that are unique to each customer’s data set. These details are summarized on the Customer 360 tab under Customer Profile.

About the data model

The data model represents the “out-of-the-box” tables that are available to every tenant. (AmpIQ tables are available only to tenants that have added AmpIQ to Amperity and have completed the process of enabling predictive attributes.)

Important

This data model represents the starting point for all tenants. It is common for a tenant to have additional tables that support specific data requirements and workflows.

Data tables

The following diagram shows the data model for core tables in Amperity. Color coded sections identify which groups of tables are associated with customer profiles, interactions records, Stitch QA, and AmpIQ.

The core data model for Amperity.

Note

Click this diagram to open it in your full browser window. Click HERE to open this diagram in a new tab or right-click that link to save a copy to your computer.

There are four groups of tables in this diagram:

Group name

Description

Customer records

The color associated with the customer profile table group.

A customer profile is a collection of attributes that are associated with a single unique individual in the customer 360 database. The total number of customer profiles is equal to the total number of rows in the Customer 360 data table. This total correlates strongly, but not exactly, to the total number of Amperity IDs assigned to unique individuals in the same data set.

The Customer_360 table represents your primary set of customer profiles and is the most common starting point for building segments. Each customer profile is built using a combination of the Merged_Customers, User_Attributes, Unified_Customer, and Unified_Coalesced tables.

Interaction records

The color associated with the interaction records table group.

An interaction record is a row in a customer data table that contains information about customer behavior, such as purchases (items bought, items returned, costs of items, etc.) and preferences (brands, products, cart adds, etc.).

Interaction records rely on a series of tables: Transaction_Attributes, Transaction_Attributes_Extended, Unified_Itemized_Transactions, Unified_Transactions, and Unified_Product_Catalog.

Each Amperity ID in the Customer_360 table can be associated to many rows in the Unified_Transactions table, and then each Amperity ID in the Unified_Transactions can be associated to many rows in the Unified_Itemized_Transactions table. Each Amperity ID in the Customer 360 table is associated to one Amperity ID in the Transaction_Attributes table.

Note

The Transaction_Attributes table has an associated “extended” table that captures additional attributes when data sources provide to Amperity the data required to complete the calculations for the attributes. It exists as a separate table in the customer 360 database, but should be viewed as a subset of transactions attributes data.

Stitch results

The color associated with the Stitch results table group.

Stitch QA is a process that monitors the quality of Stitch results. Stitch QA has two components: a database and a set of queries. The results of these queries are analyzed to help identify values that should be labeled or blocklisted and discover situations where the results of the Stitch process require tuning to match your tenant’s data set.

Stitch QA activities rely on a series of tables: Unified_Coalesced, Unified_Scores, Detailed_Examples, Unified_Preprocessed_Raw, Unified_Changes_Clusters, and Unified_Changes_PKs. These tables are the basis for the Stitch QA process; the specific use of individual tables will vary from tenant to tenant. Togehter they provide visibility into how Amperity grouped (or did not group) individual customer records to a single Amperity ID.

AmpIQ

The color associated with the AmpIQ table group.

AmpIQ enables customer-centric marketing campaigns. Use segment insights to build high-value segments. Use those segments to add audiences to campaigns. Build campaigns that send those audiences to any combination of downstream marketing workflows.

AmpIQ tables are enabled for users of AmpIQ and are the results of the configuration and tuning of Amperity for predictive analytics. These tables rely on the Merged_Customers, Unified_Itemized_Transactions, and Unified_Transactions tables for predictions, but there is not a 1:1 or 1:many relationship between those three tables and AmpIQ tables. The Predicted_CLV_Attributes table contains one row per Amperity ID, whereas the Affinity and Recommendation tables contain many rows per Amperity ID.

The Campaign_Recipients table contains a history of all campaigns that have been sent from Amperity. This table is updated on a recurring basis and may be used like any other table in your customer 360 database.

Data model indicators

This diagram uses the following indicators to highlight relationships between tables and to call out fields that are primary keys, establish links between tables, or associate this table back to a domain table in the Sources tab:

Name

Description

1:1, 1:many

An indicator that this column has a 1:1 or 1:many relationship with another table.

Indicates that this table has a 1:1 or 1:many relationship with another table. For most tables, this relationship is based on the Amperity ID.

Many:1

An indicator that this column has a many:1 relationship with another table.

Indicates that this table has a many:1 relationship with another table. For most tables, this relationship is based on the Amperity ID.

Primary key

An indicator that this column is a primary key.

Indicates this column is the primary key for this table.

Linking key

An indicator that this column is a linking key.

Indicates this column links customer records, such as those associated with a customer key or a foreign key that were defined as part of a feed or custom domain table from the Sources tab.

Data source

An indicator that this column is associated to the original data source.

Indicates this column is associated to an original customer data source in the Sources tab, with the value of this field being the name of that data source.

Spark SQL

Spark SQL is a high performance SQL query engine that is used by Amperity to ingest data, create domain tables, and extend the outcome of the Stitch process in your customer 360 database.

Queries

Queries enable you to discover lists of customers, get insight into their preferences and habits, identify properties and characteristcs of that list, and then use that list to initiate marketing actions, campaigns, and other downstream workflows.

Queries also enable you to write SQL that can be used to perform QA against various databases and tables in the customer 360 database.

The Queries tab in Amperity.

The Queries tab provides a SQL interface for building queries. Use the visual editor to build queries with drop-downs and picklists. Use the SQL editor (and Presto SQL) to build more advanced queries. The Queries tab keeps a list of all queries, in both active and draft states.

Both editors can access all tables in the customer 360 database, which contains all of your important customer attributes, along with passthrough tables that bring data that was pulled to Amperity from the domain tables to the customer 360.

Query editor

The SQL Query Editor is the user interface for a full SQL query engine based on Presto SQL that interacts with customer database tables in Amperity. The SQL Query Editor relies primarily on using the SELECT statement, along with common table expressions, joins, functions, and other components of Presto SQL to build and design advanced queries.

The Visual Query Editor located within the Queries tab in Amperity.

Presto is a distributed SQL query engine that is designed to efficiently query vast amounts of data using distributed queries. Presto is used by the Amperity SQL segment editors to define segments, which are SQL queries that return data from stitched data tables.

Because the SQL editor uses Presto SQL, you can also write any query directly as SQL.

The SQL Query Editor located within the Queries tab in Amperity.

Send to downstream workflows

You can send data from the customer 360 datasbase to any downstream location or workflow. There are two ways to do send data:

  1. By using Presto SQL to send only data that is returned by a query to a configured destination

  2. By exporting a database or a table

Export databases and tables

A database may be configured to export one (or more) tables or an entire database from Amperity. Each data export must be assigned a unique name. A data export must be associated with a configured destination and must be added to an orchestration.

Business Intelligence Connect

Business Intelligence Connect is an Amperity-managed cloud data warehouse that provides an easy-to-access location from which you can use any BI tool to access all of your Amperity data.

Business Intelligence Connect supports all of the leading BI tools, including Tableau, Looker, Domo, Qlik, Microsoft PowerBI, Amazon QuickSight, Oracle Business Analytics, and SAP Business Objects, along with any BI tool that can connect to a data warehouse using the Open Database Connectivity (ODBC) or Java Database Connectivity (JDBC) standards.

Business Intelligence Connect is available upon request for Amperity tenants who have licensed Amp360. After the data warehouse for Business Intelligence Connect is configured by Amperity for your tenant, you can send data from Amperity to the data warehouse, and then connect any of your BI tools to that data.