Below is Taguchi's standard data schema.

This is the starting point for all our custom integrations and does not relate to any standard Taguchi functionality. If you would like to discuss a custom integration or the schema below in more detail, you are welcome to contact 'Taguchi Support'.

Customer data

Standard profile fields

Field	Description	Encoding/format
id	Taguchi subscriber ID	64-bit integer
ref	external ID	UTF-8 text
email	email address	UTF-8 text
title	salutation/title, e.g. Mr, Ms	UTF-8 text
firstname	first name	UTF-8 text
lastname	last name	UTF-8 text
address	first line of postal address	UTF-8 text
address line 2	second line of postal address	UTF-8 text
address line 3	third line of postal address	UTF-8 text
suburb	city / suburb	UTF-8 text
state	state	UTF-8 text
postcode	postcode	UTF-8 text
country	country	UTF-8 text
gender	customer-specified gender	UTF-8 text
dob	date of birth	ISO8601 date, YYYY-MM-DD
phone	contact mobile, with international prefix if not Australian (used for SMS)	Numeric characters only
global_unsubscribed	global unsubscribe flag, null/blank if not globally unsubscribed, otherwise the date/time at which the customer unsubscribed	ISO8601 timestamp, YYYY-MM-DDTHH:MM:SS
invalid_email	email invalid flag, null/blank if the email address is valid, otherwise the date/time at which the address was marked as invalid	ISO8601 timestamp, YYYY-MM-DDTHH:MM:SS

See 'Subscriber Data Overview' to understand the data types for each standard field.

We do not recommend specifying Taguchi IDs directly, instead the External ID should be used to link our profiles 1:1 with records from the source system.

Each record must include a value for at least one of the following fields: id, ref, email, phone. All other fields are optional. Blank values do not overwrite existing data by default, however this can be configured in our importer.

In addition to any/all of the standard profile fields, 'custom fields' may be included in files.

'Custom fields' contain arbitrary UTF-8 text, and may be given any name except for the names of the standard profile fields above.

We typically configure our importer to validate that all required custom fields are present, however we can also enable on-the-fly creation of new custom fields for any additional columns in the imported data file.

Transaction data

Standard transaction fields

• total: the total value of this transaction
• timestamp: the date/time at which this transaction took place (ISO8601 timestamp, YYYY-MM-DDTHH:MM:SS)

Keys:

• id: a unique identifier for this transaction (UTF-8 text)
• subscriber_ref: matches the ref field of the subscriber responsible for this transaction (UTF-8 text)

In addition to the standard fields, custom fields may be included in transactions. Custom fields may contain arbitrary UTF-8 text.

Transaction line items may be supplied as JSON objects within the transaction data file, or may be supplied in a separate file with a transaction ID key matching the values in the transaction data file.

Transaction line item data

• id: a customer-assigned product ID (UTF-8 text)
• price: per-unit price for the product (real)
• qty: the number of units purchased (real)
• sale: whether or not the product was on sale (boolean, true/false)

In addition to the standard fields, custom fields may be included in transaction line items. Custom fields may contain arbitrary UTF-8 text.

If transaction line items are specified in a separate file, the file must contain a "transaction_id" field which will be used to link transaction line items back to their transaction records.

Product data

For use-cases where targeting queries are run on product attributes such as category hierarchy, it is more efficient to load these attributes into our product data store, rather than passing them as transaction line item fields. A product data file must contain an "id" field which uniquely identifies the product, plus any number of uniquely-named product attribute fields. All product attribute fields are arbitrary UTF-8 text.

---