Send query results to Infutor

Infutor is a consumer identity management platform that helps brands understand their consumers and make informed marketing and risk decisions using a secure, privacy compliant foundation to improve inbound engagements and outbound marketing reach, and to minimize fraud and collections risk.

This topic describes the steps that are required to send CSV files to Infutor from Amperity:

  1. Build a query

  2. Add orchestration

  3. Run orchestration

Note

Infutor must be enabled before you can configure an orchestration to send query results. Ask your DataGrid Operator or Amperity representative to enable Infutor for your tenant.

Build query

You may need to build a query that shapes the data so that fields in the output are mapped to the fields required by Infutor. Data shaping is typically required only one time.

You can do this in the following ways:

  1. Add a SQL table (using Spark SQL) to the customer 360 database that selects PII fields from the Customer 360 table, and then outputs them to a table with columns that map to the required naming patterns.

    Note

    PII fields may require SHA-256 hashing or conversion to a UUID using the CAST() function.

  2. Add a SQL query (using Presto SQL) that filters within the query, and then outputs results that map to the required patterns.

    Note

    PII fields may require SHA-256 hashing or conversion to a UUID using the CAST() function.

The correct approach here depends on the data and the desired use case (or cases) for downstream workflows.

Infutor and PII data

Data that is sent to Infutor primarily contains PII for use with building and maintaining enriched customer profile data for downstream workflows.

In certain cases, it may be necessary to hash the data, such as for birthdates or for other individual-specific identifiers like a social security number (SSN).

If a field does require hashing, use one-way SHA-256 hashing or cast the value to a random unique identifier (UUID).

One-way SHA-256 hash

Apply one-way SHA-256 hashes to fields that contain PII data. A one-way hash ensures that data can no longer be recognizable as valid PII, yet still allows that data to applied to segments that report on users who were flagged for removal or deletion and helps ensure that removed or obfuscated data is not sent from Amperity.

A one-way SHA-256 hash has the following syntax:

TO_HEX(SHA256(TO_UTF8(UPPER(TRIM(FIELD)))))

and uses the following Presto SQL functions:

  • TRIM() removes whitespace from the field.

  • UPPER() sets all characters to upper-case.

  • TO_UTF8() converts the data into a binary format.

  • SHA256() hashes data with a one-way SHA-256 hash.

  • TO_HEX() converts the binary data into a string.

For example:

TO_HEX(SHA256(TO_UTF8(UPPER(TRIM(Birthdate)))))

CAST as UUID

Use the CAST(value AS type) function to cast the value of value as type.

For example:

,CAST(birthdate AS UUID) AS "Birthdate"

Map fields to Infutor

The following SELECT statement collects data from Amperity and maps it to the preferred field.

SELECT
  ,amperity_id AS "Amperity ID"
  ,full_name AS "Full Name"
  ,given_name AS "First Name"
  ,surname AS "Last Name"
  ,address AS "Address1"
  ,address2 AS "Address2"
  ,state AS "State"
  ,postal AS "Zip5"
  ,phone-1 AS "Phone"
  ,phone-2 AS "Phone2"
  ,email AS "Email"
  ,ip_address AS "IP"
FROM Customer360

Infutor field reference

Map fields in Amperity to the following fields in Infutor. (The Amperity column lists the names of the fields as if they were identical to the semantic tag associated with that field.) Most Infutor fields allow alternate field names.

Important

Talk to your Infutor Solutions Engineering representative about date of birth (DOB) or social security number (SSN) data prior to sending results with that data to Infutor.

Amperity column

Infutor field

Description

full_name

Full Name

A combination of given name (first name) and surname (last name) that is associated with an individual customer record and is stored as a combined value in a single field within customer data. A full name may include a middle name or initial.

Alternate field names: Full Individual Name, UnparsedName, FullName, Full_Name, Full_Individual_Name, Individual_Name, and Name.

given_name

First Name

The first name that is associated with an individual customer record.

Alternate field names: FName, Given Name, Given_Name, and First_Name.

surname

Last Name

The last name that is associated with an individual customer record.

Alternate field names: LName, LastName, Surname, Last_Name, Family Name, Family_Name, and FamilyName.

address

Address1

The address that is associated with the location of an individual customer record. For example: 123 Main Street.

Alternate field names: Address Line 1, Address_Line_1, Address 1, Street Address 1, and Full Address.

address2

Address2

Additional address information, such as an apartment number or a post office box, that is associated with the location of an individual customer record. For example: Apt #9.

Alternate field names: Address Line 2, Address_Line_2, and Address 2.

state

State

The state or province that is associated with the location of an individual customer record.

Alternate field names: State_Code, StateCode, and State Code.

postal

Zip5

The zip code or postal code that is associated with the location of an individual customer record.

Alternate field names: Postal Code, Postal_Code, and 5 Digit Zip Code.

phone

phone-1

Phone

The phone number that is associated with an individual customer record. A customer record may be associated with multiple phone numbers.

Alternate field names: Phone Number, Phone_Number, Telephone Number, Telephone_Number, Phone1, and Telephone.

phone-2

Phone2

An additional phone number that is created by phone ordinal semantic tags that are used when multiple phone numbers are available in the source data.

Alternate field names: Second Phone, Second Phone Number, Second_Phone, Second_Phone_Number, and Phone Number 2.

email

Email

The email address that is associated with an individual customer record. A customer record may be associated with multiple email addresses.

Alternate field names: Email Address and Email_Address.

[no default]

IP

The IP address associated with this individual, if available.

Alternate field names: IP Address.

Add orchestration

An orchestration defines the relationship between query results and a destination, including the location to which those query results will be sent and the frequency at which the orchestration will be run.

To add an orchestration

  1. From the Destinations tab, click Add Orchestration. This opens the Add Orchestration dialog box.

  2. From the Object Type drop-down, select Query.

  3. From the Object drop-down, select the query for which results will be sent to Infutor.

  4. From the Destination drop-down, select a destination that is configured for sending data to Infutor.

  5. From the Data Template drop-down, select a data template.

  6. Verify all settings.

  7. Set the workflow to Manual. (You can change this to automatic later, after verifying the end-to-end workflow.)

  8. Click Save.

Run orchestration

Run the orchestration manually to validate that it works.

To run the orchestration

  1. From the Destinations tab, under Orchestrations, open the    menu for the Infutor orchestration, and then select Run.

  2. The Status column for the orchestration will update to say “Waiting to start…”, after which the notifications pane will update to include a notification that shows the current status.

  3. When the orchestration has run successfully, the status is updated to “Completed”.