Tie writes identified shoppers and their browsing activity into your Bloomreach project, and reads your existing customer and event history back out. Setting that up has three parts. Your team creates the fields Tie sends, you create an API group for Tie and send back six values, and you grant read access to your Bloomreach data in BigQuery.

Everything below is either read access or a scoped API group. Tie does not ask for the ability to edit or delete anything in your Bloomreach project.

Bloomreach silently discards any value written to a property or event it does not already know about, and it matches on the literal name. There is no error and nothing lands in a holding area, the value is simply dropped. So please create every name below exactly as spelled, including capitalization, and create them before we start sending. Anything defined later is data that cannot be recovered.

These are populated on a customer profile when Tie identifies a visitor. Example values are illustrative.

Five more are populated on each identified profile. These are not fields you would build segments on early, but Tie writes to them, so they need to exist or the values are discarded on arrival.

Each action is sent under more than one event name, depending on which Tie identification source the visitor came from, so please create every name listed. rr_event_id appears on every event.

Events carrying three properties. Create Tie Page View, Tie Prospect Page View, Tie Add to Cart, and Tie Prospect Add to Cart.

Events carrying ten properties. Create Tie View Item, Tie Prospect View Item, and Tie Add To Cart.

Tie Add to Cart and Tie Add To Cart (one with a capital "T") are two different events, not a typo. One carries three properties and one carries ten. Please create both, exactly as written.

One more, only if your project needs it. Bloomreach creates merge automatically when the connection is established. It needs creating by hand only if your project does not allow automatic event creation, in which case it takes five properties. requested_ids (string), source_internal_ids (list), destination_internal_id (string), final_external_ids (string), and original_external_ids (string).

In your project settings, under API, create a new API group. Set Access type to Private access and the Group name to Tie. Private access is what produces an API key ID and secret pair, which is what our server-side integration authenticates with. A public access token will not work for writing profile data.

On the group's permissions screen, tick both Get and Set for every Tie custom property under Customer properties, and for every Tie event under the Events tab. Please also tick Get and Set on New properties, so anything added later does not quietly fall outside the group's permissions.

This is the step most easily missed. A group can hold valid keys and still lack permission on a property, so it is worth confirming before you call the setup done.

Two of the values we need are read off a segmentation, so this one is required rather than optional. Create a segmentation named Tie_updated containing a single segment, with the customer filter set to matching attribute Tie_updated less than three hours ago, then save it.

It reads zero customers until we start sending, which is expected. Once we are live it doubles as the quickest check that the connection is working. If it populates, Tie is writing to your profiles.

Four come from the API screen and the group you created, and two come from the segmentation in step 5.

The API key ID and secret are the only sensitive values here. For the safest way to get them to us, see How to send Tie your credentials securely. The other four are safe to send however you normally would.

Please grant Data Manager access to the addresses below. That is read access on your definitions, so we can confirm your properties and events match what we send before any data flows. It does not include campaign rights or the ability to export your customer data.

Revenue Roll is Tie's legal entity name, which is why one of those addresses sits on a different domain.

The API and BigQuery do different jobs. The API is how Tie writes to profiles as people browse your site. BigQuery is how we read the customer and event history already in your project, which the API cannot return in bulk.

First, send us your project, dataset, and table list. Before you grant anything, send the Google Cloud project and dataset name plus the list of tables with their schemas. Bloomreach lays this out differently from project to project, so we would rather read your layout than guess at it.

Then grant read access on two tables at minimum.

How much history. As much as you have, and at least a year. With a shorter window, someone who last visited before it starts looks new to us, so returning visitors get counted as new ones. This is the history already in your Bloomreach project, separate from the Tie events you created in step 2.

The access level is read only, and it takes two roles. BigQuery Data Viewer on the dataset and BigQuery Job User on the project, granted to [email protected] and [email protected]. Please add both. Data Viewer on its own reads as granted and then fails on every query. Neither role allows writing or deleting anything.

We compare your definitions against what we send, confirm the types line up, and flag anything that needs adjusting before a single event is sent. That review is what prevents data going missing later. Your Tie contact confirms when the connection is live and your data is flowing.