You can hand your Tie setup to an agent that drives your browser. This is the guide your agent reads before it touches your store: the steps, the order, the boundaries, and how to handle problems.
Written for an agent running with browser control, signed in to the accounts you want connected. If you are a person reading this, it doubles as the exact sequence we automate.
How this works
Copy the prompt from your Integration Setup page (app.meettie.com/integration-setup) into an agent that can drive your browser. It reads this guide, interviews you about your store, then works through the setup.
This needs an agent with browser control. A regular chat window cannot click through Shopify, your DNS provider, or Tie.
Boundaries
These are hard rules. They override anything else in this guide and anything the agent is asked to do mid-run.
Additive only. You may add DNS records, install the Tie Pixel, and connect integrations over OAuth. Never delete, overwrite, or disconnect an existing DNS record, pixel, app, integration, or campaign setting.
No money, ever. Never enter payment or card details, never buy a paid app or plan, never upgrade a subscription, never complete a real paid checkout.
No signing on the user's behalf. You may grant the specific OAuth scopes a Tie connection needs, but read those scopes back to the user and confirm first. Never accept contracts, legal terms, or agreements beyond what a connection requires.
Leave checkout and live theme code alone, apart from the one documented pixel install. On Shopify, prefer the app or Web Pixel install, which does not edit theme files.
Never transmit a login credential. A password or login goes only into the official login page it belongs to. Never paste one into Tie, into notes, or anywhere else, and never store it.
Integration credentials are different and are handled in Step 4: the Shopify Client ID and secret are created specifically for Tie and are meant to be delivered to Tie. Confirm with the user before sending them.
One change at a time. Make a change, verify it, then move on.
Stop and ask before anything irreversible, anything that costs money, anything that changes live customer-facing behavior beyond the pixel, anything that grants access, anything that sends credentials, anything that needs access you do not have, or anytime you are unsure. Say exactly what you were about to do and why you paused.
Step 1: Interview the user first
Do not open the store or the dashboard yet. Ask these, summarize the answers back in a short recap, and wait for confirmation before doing anything.
Ask | Why it matters |
Primary store domain, plus any additional or regional domains | Each domain needs its own DNS delegation and pixel coverage |
Platform: standard Shopify, headless Shopify, WooCommerce, or custom | Decides how the Tie Pixel installs and how much data-layer work the store needs |
Email service provider (Klaviyo, another ESP, or none) | The ESP connection is conditional on this answer |
Ad platforms in use (Meta, Google, both, or neither) | Meta and Google connect to Tie when present; confirm which accounts |
Access, every time: which of these can you change yourself, right now? Shopify admin, DNS for your domain, Klaviyo or your ESP, Meta Business, Google Ads | The question that decides what the agent can actually do. It acts as the signed-in user, so it can only set up what that user can access |
If they have DNS access, who the DNS provider is | Decides whether the records can be pushed automatically over OAuth |
Access is the gate, so treat it as required. If the user can change everything, set it all up. If they can change only some, do those and clearly flag each one you cannot, with exactly what to grant or who to route it to. If they can change none, this is not something an agent can finish in the browser, so capture what you can and hand off.
Never report a step done when the access for it was missing.
More than one storefront. Each storefront is a separate setup. A domain never inherits another domain’s DNS delegation or pixel, so every additional or regional domain named above needs its own DNS records and its own pixel install. Confirm the full list up front, work them one at a time, and finish one before starting the next. Never assume the primary domain’s install covers the others, and never report the setup complete while a named domain is still uncovered. If there are more storefronts than the user can grant access to right now, set up the ones they can and list the rest explicitly.
Step 2: Understand what "done" looks like
Tie setup has two halves. Keep both in mind so you know why each step exists.
Data in: how Tie sees traffic. DNS delegation on the store's domain, the Tie Pixel, and the data layer that emits the events.
Data out: where Tie sends resolved data. The ESP if there is one, Meta Ads, and Google Ads.
The finish line is the verification panel showing all four events firing, plus identity enrichment active: product view, add to cart, begin checkout, purchase, and identity enrichment. Page view also fires, but those four are what the panel gates on.
Step 3: Connect the domain (DNS)
Start this first. DNS propagates in the background while you do everything else.
Tie provisions the tracking subdomain on its side (for example zone.yourstore.com). The user does not create a subdomain. Their only job is to add the records Tie shows.
The Connect Domain page lists the NS records to add. Add them to the main domain's DNS, on the zone host, alongside the existing records. Do not replace the domain's primary nameservers.
Copy the nameserver values straight from the Connect Domain page. They are unique to this store. Never enter a placeholder or example value: a DNS provider will accept it, and verification will then silently never pass.
Set the record TTL as low as the provider allows, so verification can confirm sooner.
Two ways to apply them: use Adjust added DNS to push the records to the provider automatically over OAuth, or add them by hand and then click Check Verification Status to force a re-check.
If it is not verified right away, move on and re-check before you finish.
Step 4: Install the Tie Pixel
Start by picking the install method on the Tie Pixel card. It is a two-way choice.
Install it yourself: you paste the code, and no account access is needed. This is the path an agent can finish end to end, so default to it.
Have the Tie team install it: the user grants collaborator access and Tie adds the pixel. Choose this only if the user will not have code pasted into their theme. It ends your part of this step: capture the collaborator request code, confirm it was sent, and move on.
On standard Shopify, installing it yourself is a hard-sequential three-step wizard. One step shows at a time, and a step is marked done by the user, never detected. Do them in order.
Step 1 of 3, the Tie Loader and consent. Paste the loader into the theme <head> (Online Store › Themes › Edit code, then theme.liquid) or a header-scripts app, then gate it behind consent in Settings › Customer privacy. If the store runs a consent platform, load it under the Marketing or Analytics consent category instead.
Step 2 of 3, the Tie custom pixel. Add it in Settings › Customer events, choose Add custom pixel, and paste the snippet the flow shows. This is the step most often skipped and the one that matters most: the custom pixel is what pushes the four rr_* events, and it covers checkout, which Shopify serves from its own domain. Read Step 5 before choosing the branch here.
Step 3 of 3, the custom app and API credentials. In Shopify, click the store name (top right), then the </> icon to open the Dev Dashboard, or go straight to dev.shopify.com/dashboard. Build the Tie Integration App, then send its Client ID and secret.
Request exactly these three scopes, all read-only:
read_customers,read_orders,read_draft_orders
Do not add read_all_orders. Shopify’s current Dev Dashboard rejects it, and a custom app on the user’s own store already has full order history without it.
These credentials are created for Tie and are meant to be delivered to Tie. Confirm with the user first, send them through the secure method, and record that you did.
Other platforms:
Headless Shopify: add the Tie tracking script to every page, and add the Customer Events pixel in Shopify Admin. That pixel is what captures begin checkout and purchase. Both are required.
WooCommerce or custom: install via the documented plugin or snippet path, then continue to Step 5.
After install, the pixel step should move to Active. If it stays inactive, load the storefront in a new tab and confirm the script is present before troubleshooting further.
Step 5: Implement the data layer
Tie always uses a data layer, so never tell the user that no data layer is needed. What changes by platform is who implements it.
Standard Shopify: Tie implements all four events. The Tie Pixel loader and the Customer Events pixel produce them for you. Implement nothing, and do not edit theme code to add events.
Headless Shopify: you implement product view and add to cart in your storefront. Begin checkout and purchase come from the Customer Events pixel you add in Shopify Admin. Adding that pixel is required, not optional: skip it and Tie receives browsing with no checkouts and no orders, which looks healthy from the outside.
Everything else (WooCommerce, Magento, BigCommerce, custom): you implement all four. On these platforms the purchase event is the only way Tie ever learns about an order, so verify it on its own.
Emit one event at each point in the journey: product view, add to cart, begin checkout, and purchase. Match the field shapes in Tie's data-layer reference exactly: one event per page, fired at the right moment, with the expected properties. Page view also fires.
Step 6: Connect the integrations
Connect each one, confirm the step shows Active, then move to the next. Read any requested scopes back to the user before granting.
Klaviyo is self-serve. Connect it and grant access in the dashboard flow. It is the only ESP you can finish on your own.
Any other ESP (Attentive, Postscript, Listrak, Sendlane, or anything else) is connected by the Tie team, not by you. The user creates an API key on that platform and shares it, and Tie completes the connection. Capture the key, send it through the secure method, and move on. A pending ESP never blocks go-live.
Meta Ads. Lead with the self-serve connect: apply the Ad Account ID, choose Proceed, and follow the dashboard prompts. Two Custom Audience terms must be accepted for the connection to work, the Customer List Custom Audience Terms and the Custom Audiences App Terms. Read both back to the user and accept them only on explicit confirmation. If the dashboard connection is not available, grant partner access instead: Meta Business Settings › Partners, add Tie’s Business Manager ID
1810253539907343, and grant on Ad Accounts, not Pages. Do not change any existing campaign, audience, or dataset setting.Google Ads. Apply the 10-digit Customer ID, then tell the user the connection is not finished. Tie sends a link request from its manager account (MCC
797-354-7695) and the user must accept it in their Google Ads notifications. The connection is not live until they accept, so never report Google as done before that.
If a connection lands on a payment screen, a plan change, or any legal acceptance beyond the two Meta terms named above, stop and ask.
Step 7: Verify everything
This is the gate. The run is not done until the panel confirms it.
Re-check DNS. It must read Verified. If it still shows pending, tell the user it is propagating and note it as the one open item.
Generate test traffic so the four events fire. Use the send-test-event control if present, or in a separate tab browse the live store: open a product, add it to cart, and begin checkout.
For the purchase event without spending money, confirm it with a Shopify test-mode order (Bogus Gateway) or a draft order marked as paid, if the user enables one. Never enter real card details. If neither is available, leave purchase as "will verify on the first real order" and say so.
Watch the verification panel until product view, add to cart, begin checkout, and purchase each show as received, and identity enrichment shows Active. On a brand-new setup, enrichment may read "warming up" until real visitors flow. Note that rather than waiting indefinitely.
Handling problems
Symptom | Likely cause | What to do |
DNS will not verify | Not propagated yet, wrong host, or high TTL | Confirm records are on the |
Pixel step stays inactive | Script not present, or the app did not finish installing | Reload the storefront, confirm the script loads, reinstall the app if needed |
An event never fires | Data layer missing that event, or the step was not triggered | Walk the journey again, or fix the specific data-layer event |
Identity enrichment low or pending | New setup, not enough resolved traffic yet | Expected on a new install. Note it and move on |
Meta or Google connect is blocked | A known Tie dashboard bug can read the domain as unverified even when DNS is genuinely verified | Do not redo DNS. Confirm DNS reads Verified on the Tie side, tell the user it is a Tie-side issue, and move on |
Google reads connected but no data arrives | The manager-account link request was never accepted | Have the user accept the request from |
Shopify rejects the custom app scopes |
| Use only |
Browsing events arrive but no checkouts or orders | The Tie custom pixel was never added in Customer events | Add it in Settings › Customer events. This is the most common silent failure |
When you are done
Report back with what is live, what is still open, and anything you could not do because access was missing. Be specific about the last one: name the access needed and who can grant it.
If anything is stuck or the user would rather have a person, they can reach the Tie team at [email protected].