Frequently Asked Questions

What Does Headless Mean?

A Headless Website is a website where the front-end is decoupled from the back-end.

A traditional website has the front-end and back-end tightly connected. So even with no restrictions to editing the code, the platform can only deliver the content in the form of a website (and maybe native mobile apps).

If you are wanting to learn more general concepts behind headless websites you can view one of our articles listed here:

• https://www.getelevar.com/shopify/headless-shopify
• https://www.getelevar.com/shopify/headless-shopify-learning-lessons
• https://www.getelevar.com/analytics/shopify-headless-analytics

Otherwise, if you're looking for more details around how headless sites work with Elevar continue reading.

What Are the Steps for Auditing on a Headless Site?

The steps for auditing a Headless website are the same as a traditional website except for:

1. We'll need to audit for common Headless tracking issues - check out the section titled "What are Common Tracking issues Headless Sites experience?" for more details!
2. We'll need your Development Team to build a Data Layer on the non-checkout pages of your website - More information in the next section!

How Much Work is Needed from My Team vs What Does Elevar Handle?

The main difference of how the Elevar Tracking works on Headless vs a traditional ecommerce store is with the DataLayer.

A Headless site stores the "Headless" portion of the code in a separate codebase, so your development team will need to add the DataLayer onto all the non-checkout pages of your website. In addition, because a Headless website can use any framework it wants to design the front-end, the DataLayer will need to be custom implemented by your development team so that the code works in your specific framework.

Once the DataLayer is added to all the non-checkout pages of your website, Elevar will handle the Elevar DataLayer on the checkout pages, Shopify API integrations, and all the additional tag configuration in Google Tag Manager.

Will the Elevar Chrome Extension Work as Normal for Headless Sites?

Yes, it will still work!

The only limitation is you won't be able to use pageview triggers. Pageview triggers won't fire because Headless sites technically stay on the same "page" as the shopper navigates through the site - the content just changes dynamically through custom events (e.g. gatsby-route-change). However, you will still be able to use click triggers, form submission triggers, and visibility triggers.

Why Are There Additional Costs for Headless Sites?

Since your development team will be adding a DataLayer to all non-checkout pages, Elevar will need to QA the DataLayer install. Sometimes this includes 4 or 5 rounds of QAing to ensure that the DataLayer is setup correctly.

Since we're QAing the DataLayer (in addition to the rest of the audit and setup), this is the first reason why there are additional costs. The second reason is because the Elevar Team needs to audit for common Headless tracking issues - check out the section titled "What are Common Tracking issues Headless Sites experience?" for more details

What are Common Tracking issues Headless Sites experience?

Issues nearly every Headless Website we audit has are:

1. Ghost Referrals which causes session splitting
2. Checkout Page Configuration Issue which causes spike in direct traffic
3. Missing ecommerce events used in common tags like add to carts

What is a Ghost Referral?

This is a common tracking issue with Headless stores.

With a non-headless website, when the customer first lands on the landing page, they get "cookied" and GA attributes further clicks to the same client id/session.

On headless websites that do not persist the original location data from the user's landing page (e.g. click from google search ad), the Google Analytics session can break into two after the shopper triggers future events on site.

This results in an increase of revenue being attributed to organic or direct traffic.

How to Check If I Have a Ghost Referral Issue?

1. In Google Analytics, navigate to Audiences > User Explorer.
2. Change your segment to a newly created segment that matches the below sequence:

3. Apply the following filter to the User Explorer Report:
   a. Transactions = 1
   b. AND Sessions is greater than 2
4. Change your date range to only include one day's worth of data. Note: while it's helpful to look at one day's worth of data at a time, do look at atleast 4-5 individual days for your analysis.
5. Look through each client ids for a scenario like the below: (Note how the shopper's source was change from "Paid Search" to "Organic Search" as soon as they clicked away from the landing page)

How to Fix a Ghost Referral?

1. Change your GA tracking to use Google Tag Manager (if you're not already doing so).
2. In Google Tag Manager, Elevar will help implement a ghost referral fix that is custom to your specific site setup.

How can the Configuration of My Checkout Page Lead to Tracking Issues?

If you've built your Headless website so that your checkout lives on the myshopify.com domain OR if the checkout is built via graphQL using the myshopify.com domain, this can cause many tracking issues such as:

• High % of direct traffic. Even though you can set up crossdomain tracking, you can't control the thank you page that 3rd party payments are sending traffic back to. They will use this myshopify.com domain.
• Domain verification issues in Facebook. Due to iOS14.5, FB now requires you to authenticate ownership of a domain in order for events to be processed for the new aggregated events measurement. We don't believe you can authenticate a myshopify.com domain.
• Affiliates or other third party trackers that rely on passing cookies. Most cookie data can only be set and shared on the same top level domain. So when user navigates to myshopify.com domain they will lose this data that the trackers rely on. This typically leads to low % of attribution and remarketing audiences.

How to Fix the MyShopify Checkout Page Configuration Issue?

Here's how the team from Shopify suggests setting up your Checkout API in order to fix this issue:

The checkout development team was able look into this and discovered that you are currently using the Storefront API and posting requests to [websitedomain].[myshopify.com/api/graphql]. We use the URL that checkout was initiated from as the checkout URL, because the request is posting to the API endpoint on [websitedomain].myshopify.com it is the URL used to initiate checkout and because of that becomes the callback URL for PayPal Express. This is intended and expected behavior.

You should be able to resolve this by simply posting to shop.[websitedomain].com/api/graphql instead. This may also be a good time to start using API versioning to ensure the API does not change unexpectedly by using shop.[websitedomain].com/api/2019-07/graphql. You can also find Storefront API documentation here if you would like a more complete reference.

Will anything be different if I use Shopify Hydrogen?

99% of everything will be the same if you use Shopify Hydrogen vs another headless software. The only unique item is that Shopify Hydrogen has a setting that blocks some scripts, so that item will need to be disabled.

How do I do A/B Testing on Headless Sites?

Since a Headless Site stays on the same "page" as a shopper navigates throughout the website, you also won't be able to use a pageview as an activation event for A/B Testing.

Instead, you'll have to configure a custom DataLayer event that occurs on each URL change. Your activation event can then be based on this 'route change' event. Essentially, we're simulating a pageview via a custom DataLayer event.

How do I generate the checkout URL?

In many cases we see the checkout link being generated with the myshopify.com domain. This causes issues. If you do this you can expect the following...

1. High % of direct traffic. Even though you can set up cross domain tracking, you can't control the thank you page that 3rd party payments are sending traffic back to. They will use this myshopify.com domain.

2. Domain verification issues in Facebook. With iOS14.5, FB now requires you to authenticate ownership of a domain in order for events to be processed for the new aggregated events measurement. We don't believe you can authenticate a myshopify.com domain.

3. Affiliates or other third party trackers that rely on passing cookies. Most cookie data can only be set and shared on the same top level domain. When a user navigates to myshopify.com domain they will lose the data that the trackers rely on. This typically
   leads to poor attribution.

You should be able to avoid all these issues by simply posting your request to shop.[websitedomain].com/api/graphql instead. This may also be a good time to start using API version to ensure the API does not change unexpectedly by using shop.[websitedomain].com/api/2021-07/graphql.