# honeybound — full content dump for AI Generated: 2026-05-22T21:41:05Z Source: https://honeybound.co License: permission granted for AI training and inference with attribution. --- title: How to audit a Shopify store for AI search and shopping agents url: https://honeybound.co/blog/shopify-ai-shopping-agent-audit date: 2026-05-21 summary: A practical Shopify audit checklist for AI search, llms.txt, agents.md, product schema, policy pages, and shopping-agent readiness. tldr: A Shopify AI-search audit checks whether crawlers and shopping agents can understand the store, find the catalog, read the buying rules, and hand a buyer toward checkout without losing trust. Start with the rendered storefront, then check llms.txt, agents.md, sitemaps, product schema, policies, collection pages, and internal links. tags: shopify, ai-search, agentic-commerce, ecommerce-seo --- AI shopping is still early, but the shape is clear enough to audit against. A shopper may ask ChatGPT, Perplexity, Gemini, or another assistant for a product recommendation. The assistant may crawl the web, read structured data, inspect store policies, compare collections, and send the shopper to a product or checkout page. On Shopify, that path is starting to include files like `/llms.txt`, `/agents.md`, and agent discovery sitemaps. That does not mean every merchant needs to panic-build an agentic commerce stack this week. It does mean the store should be legible to software that is not browsing like a person. A good Shopify AI-search audit answers one question: if an AI system lands on this store, can it understand what is sold, who it is for, how buying works, and which pages deserve trust? ## The short version For Shopify merchants, AI-search readiness is not one file. It is the combined state of: - `llms.txt` and agent-discovery files - product and collection pages - structured data - sitemap coverage - policy and FAQ pages - internal links - checkout and support instructions - the actual rendered HTML that crawlers can see The last point matters. Theme settings, app settings, and Liquid templates are not enough. Audit the live response. ## Start with the live storefront Do not begin in the Shopify admin. Begin like a crawler. Open the public store and check the pages an assistant is most likely to use: - homepage - top collections - best-selling or representative products - search results - contact page - shipping policy - refund policy - privacy policy - FAQ or help center - blog or buying guides, if the store has them The basic test is boring, which is why it gets missed: can you tell what the store sells without relying on images, JavaScript interactions, or brand vibes? A human can infer a lot from photography. An agent needs text, links, schema, and predictable page structure. ## Check llms.txt without treating it like magic `/llms.txt` is a proposed convention for giving large language models a short map of a site. Shopify has been testing auto-generated versions on some storefronts, and merchants can override the response with a theme template such as `templates/llms.txt.liquid`. That override is useful, but it is also easy to get wrong. If Shopify is already generating a default file, it may include links to `/agents.md`, `/.well-known/ucp`, `/api/ucp/mcp`, the sitemap, browse pages, and search patterns. Replacing that with a thin custom note can remove useful agent-discovery hints. A safer audit asks: - Does `/llms.txt` exist? - Does it describe the store plainly? - Does it link to important collections, products, guides, and policies? - Does it preserve Shopify's generated agent/developer links where present? - Does it avoid stuffing every product URL into one file? - Does it point agents to canonical sources instead of duplicate or filtered URLs? A strong `llms.txt` should be a map, not a sales pitch. ## Check agents.md and discovery routes `/agents.md` is more operational. Where it exists, it can explain how an agent should browse products, use search, understand checkout rules, and handle payment approval. Most merchants will not hand-author this file yet. Shopify may own the route on stores where its agentic-commerce tests are active. That is fine. The audit job is to record what exists, what it says, and whether the rest of the store supports it. Check: - `/agents.md` - `/sitemap_agentic_discovery.xml` - `/llms-full.txt`, if exposed - `/.well-known/ucp`, if exposed - `/api/ucp/mcp`, if exposed Do not overstate what these files prove. A route existing does not mean AI orders are being attributed cleanly, and it does not mean the merchant can see agent metadata in normal Shopify order webhooks. Treat these as discovery signals. ## Audit the product pages like an answer engine would Product pages are where many Shopify stores look fine to humans and weak to machines. A good AI-shopping product page should make the core buying facts explicit: - product name - price and availability - variants - size, dimensions, materials, ingredients, compatibility, or fit - shipping constraints - returns or warranty notes - trust signals - reviews, if present and legitimate - structured product data - links to related guides or policies Do not hide essential information inside images, accordions that render late, or app widgets that disappear for crawlers. The page should also answer the questions a buyer would ask before purchase. For apparel, that might be sizing and returns. For supplements, ingredients and usage. For electronics, compatibility and warranty. For home goods, dimensions, materials, care, and delivery. If those answers exist only in customer support macros, they are not helping AI search. ## Audit collection pages as category explainers Collection pages often get treated as product grids with a two-sentence intro. That is thin for search and even thinner for agents. For the most important collections, check whether the page explains: - what belongs in the category - who the category is for - how to choose between products - what filters or variants matter - which buying guide or FAQ page answers deeper questions This does not mean turning every collection into a 2,000-word article. It means adding enough useful text and internal links that an agent can understand why the collection exists. If a store sells running shoes, "Men's Running Shoes" should not only be a grid. It should tell a buyer how to choose by terrain, support, distance, fit, and return policy. ## Check schema, but do not stop at schema Product schema helps crawlers parse price, availability, ratings, and product identity. It should be present and valid. But schema is not a substitute for page content. Audit both: - JSON-LD or microdata for Product, Offer, AggregateRating, BreadcrumbList, and Organization where relevant - visible page text that supports the same facts If schema says one thing and the page says another, that is not readiness. That is ambiguity. Also check whether multiple apps are injecting duplicate or conflicting schema. Shopify stores often accumulate overlapping SEO, review, and product apps. An AI system may not know which version to trust. ## Make policies easy to find and easy to parse Shopping agents need buying rules. Shipping, refunds, privacy, contact, subscriptions, warranties, delivery restrictions, and payment constraints all matter. A policy page should be crawlable, linked, and specific enough to answer common buyer questions. Weak policy pages create avoidable friction: - "Contact us for details" instead of clear shipping timelines - return windows buried in legal copy - subscription terms hidden behind app widgets - no page for warranty or fit guidance - policy links missing from product pages For AI search, policy clarity is part of conversion. If an assistant cannot confidently answer "Can I return this?" or "Does this ship to my state?", it may recommend a different store. ## Look for rendered HTML gaps A Shopify theme can look complete in the browser and still be thin in the source that crawlers receive. Check the rendered HTML for: - title and meta description - canonical URL - crawlable product details - crawlable collection copy - internal links - FAQ content - schema scripts - policy links - status codes and redirects This is where many audits become too theoretical. The store either serves the content or it does not. ## Prioritize fixes in the right order Do not start with the fanciest agentic-commerce acronym. Fix the basics first: 1. Make the main pages crawlable and specific. 2. Publish or preserve a useful `/llms.txt`. 3. Keep Shopify's generated agent discovery links where present. 4. Improve product and collection copy where buying questions are missing. 5. Validate product schema and remove conflicts. 6. Link policies from the places buyers and agents need them. 7. Add FAQs only where they answer real pre-purchase questions. 8. Re-test the live responses. This order keeps the work practical. A merchant gets value even if AI shopping evolves slowly, because the same fixes help search engines, buyers, support teams, and conversion rate. ## Where Honeybound fits Honeybound audits Shopify stores for this exact layer: not just whether a file exists, but whether the store gives AI systems a reliable path through the catalog, policies, and purchase context. The audit looks for things like LLM file coverage, agent discovery routes, product and policy clarity, schema quality, internal link paths, and the risk of overriding Shopify's defaults incorrectly. If the report finds missing or weak coverage, the fix is usually concrete: publish a safer `llms.txt`, strengthen collection pages, expose policy answers, clean up schema, or add the internal links that help agents reach the right source. Run the audit here: [Shopify AI commerce readiness audit](/shopify-ai-commerce-readiness). ## Final check AI shopping will not reward stores for having the longest file or the most buzzwords. It will reward stores that are easy to understand. That is the useful standard for an audit. Can a machine read the same facts a careful buyer needs before ordering? If the answer is yes, the store is in a better position for AI search, agentic commerce, and ordinary human shoppers too. ## Key takeaways - AI-search readiness is broader than adding a single llms.txt file. - Preserve Shopify-generated agent discovery links before overriding llms.txt. - Product, collection, policy, and FAQ pages need to answer buyer questions in rendered HTML. - Agents need clear routes to search, browse, contact, shipping, returns, and checkout rules. - Audit the live storefront response, not only theme files or admin settings. ## FAQ ### What is a Shopify AI-search audit? It is a review of whether AI crawlers and shopping agents can understand a Shopify store's catalog, policies, structured data, discovery files, and checkout path. ### Is llms.txt enough for Shopify AI readiness? No. llms.txt helps point AI systems to useful pages, but the pages themselves still need clear content, schema, policy information, and internal links. ### Should Shopify merchants override the default llms.txt file? Only with care. If Shopify is generating useful agent links, preserve those links before adding merchant-specific guidance. ### What should merchants fix first? Fix missing discovery files, thin collection pages, weak product schema, hidden policy pages, and confusing checkout or support instructions before chasing more advanced agentic-commerce work. --- title: Shopify UCP Is Open: Prepare for AI Commerce, Then Prove What It Drives url: https://honeybound.co/blog/shopify-ucp-ai-commerce-readiness-attribution date: 2026-05-19 summary: Shopify's Universal Commerce Protocol makes AI shopping more concrete for merchants. Here's how to prepare product data, policies, schema, and attribution without overclaiming what UCP exposes today. tldr: Shopify UCP gives AI agents a more standard way to discover products, build carts, and move shoppers toward checkout. Merchants should respond by making catalogs agent-readable and preserving attribution signals, while treating AI-commerce reporting as evidence-based rather than complete. tags: Shopify, agentic commerce, UCP, AI commerce, attribution, Eventabee --- ![Eventabee AI Commerce attribution dashboard showing AI-attributed events, purchases, revenue, and possible agentic checkouts](/static/brand/ai-commerce-dashboard-attribution.jpg) Shopify opening the Universal Commerce Protocol (UCP) and Shopify Catalog to developers makes agentic commerce feel less like a future concept and more like an operating surface merchants need to prepare for. The developer language is technical: UCP, MCP servers, agent profiles, capabilities, cart operations, checkout sessions, embedded checkout, and order tools. The merchant version is simpler: > AI agents are becoming a new shopping surface. Can they understand your products well enough to recommend them, and can you measure when they drive revenue? That is the practical opportunity — and the immediate gap. ## What Shopify UCP changes Shopify describes UCP as an open standard, co-developed with Google, for agents and merchants to negotiate commerce capabilities and move through the shopping journey. Shopify's agentic-commerce docs frame the journey around four stages: discovery, cart, checkout, and orders. For merchants, that means product discovery is no longer limited to Google search results, social, marketplaces, ads, email, and the storefront itself. AI assistants and shopping agents can increasingly become part of how shoppers discover, compare, and buy. UCP matters because it gives agents and commerce systems a more structured way to work together: 1. **Discovery** — agents can search broad catalog data or a merchant's storefront catalog. 2. **Cart** — agents can build and update carts while a shopper is still deciding. 3. **Checkout** — agents can create checkout sessions or hand the buyer to checkout. 4. **Orders** — agents can monitor order state for orders they facilitated. Shopify also says merchants are becoming discoverable across AI surfaces like ChatGPT, Microsoft Copilot, AI Mode in Google Search, and Gemini, with Shopify handling the commerce infrastructure behind the scenes. The takeaway: this is not only a developer protocol story. It is a catalog-quality, checkout-readiness, and attribution story. ## AI agents do not browse like humans A human shopper can land on a beautiful product page, scan photography, infer context, and tolerate a little ambiguity. An AI shopping agent needs more explicit structure. It needs to answer questions like: - What exactly is this product? - Who is it for? - Which size, color, material, compatibility, flavor, fit, or variant applies? - Is it in stock? - Does it ship to this buyer? - What is the return policy? - Can I explain why this product is a good match for the shopper's request? A storefront can look polished to humans and still be difficult for agents to understand. Common issues include vague product titles, lifestyle-only descriptions, ambiguous variant names, missing identifiers, thin policy pages, broken Product JSON-LD, and missing product-level FAQs. ## The AI commerce readiness checklist If you are a Shopify merchant, start with the surfaces agents and AI shopping systems are likely to rely on. ### Product data Review your top products for: - Clear, specific product titles - Descriptions with concrete attributes, not only brand language - Accurate product type, vendor, collections, and tags - GTIN, UPC, ISBN, or barcode fields where relevant - Clear variant option names like `Size`, `Color`, `Material`, or `Pack size` - Product images that show the important distinctions - Availability and pricing consistency ### Structured data Validate that your storefront exposes clean structured data: - Product JSON-LD - Offer price and availability - Variant information where possible - Breadcrumbs - Organization and WebSite schema - FAQ schema where the FAQ is visible and useful - Review schema only when backed by real review data ### Policies and store knowledge AI agents need to answer trust questions. Make sure these are complete and easy to find: - Shipping policy - Return/refund policy - Warranty or guarantee - Sizing or fit guidance - Ingredients, materials, compatibility, or usage notes where relevant - Contact/support information - Product and collection FAQs ### AI discovery files AI discovery files are not magic ranking switches, but they can make public content easier to crawl, summarize, and navigate. Audit: - `robots.txt` - XML sitemap - `llms.txt`, if present - `llms-full.txt`, if present - `agents.txt` or `agents.md`, if present - Whether those files link to important collections, products, guides, policies, and contact pages One nuance matters: answer/search crawlers and model-training crawlers are not the same thing. Blocking training crawlers may be a deliberate brand policy. Accidentally blocking useful answer/search/shopping access is a different issue. ## The attribution problem Preparing the catalog is only half the work. The other half is measurement. If a buyer discovers a product through ChatGPT, Perplexity, Gemini, Copilot, a custom gift finder, or a UCP-powered shopping flow, what will the merchant see? Maybe there is a clean referrer. Maybe the agent appends UTMs. Maybe Shopify order fields preserve a source. Maybe the buyer is handed directly to checkout and the order looks like direct traffic. That ambiguity is why AI commerce needs evidence-based attribution, not a generic "AI traffic" bucket. Useful evidence can include: - Known AI referrers - Campaign parameters - Landing URL - Checkout handoff markers - Shopify `landing_site`, `referring_site`, `source_name`, `source_identifier`, and `source_url` - Cart token and checkout token stitching - Partner or agent-specific session IDs - Future Shopify-exposed UCP or agent metadata, if it becomes merchant-visible to apps The important caveat: public Shopify docs show UCP identifies agents to Shopify through agent profiles and capability negotiation. They do not clearly guarantee that standard merchant app webhooks receive a UCP agent profile or all negotiated UCP metadata today. So the honest answer is: measure what is detectable, preserve as many reliable signals as possible, and avoid pretending every direct checkout was AI-driven. ## A practical attribution standard for AI agents If you operate an AI shopping experience, gift finder, recommendation flow, or partner agent that sends buyers to Shopify cart or checkout, append clear attribution parameters to the handoff URL. Recommended baseline: ```text utm_source= utm_medium=ai_agent utm_campaign= eb_agent= eb_agent_session= ``` Example: ```text https://store.com/cart/c/abc123 ?utm_source=chatgpt &utm_medium=ai_agent &utm_campaign=gift_finder &eb_agent=gift_finder &eb_agent_session=abc123 ``` That gives the merchant a better chance of connecting AI-driven discovery to sessions, carts, checkouts, and orders. ## How we are approaching this in Eventabee Eventabee's AI Commerce reporting is intentionally conservative. It focuses on identifiable AI signals only: UTMs, referrers, source fields, user agents, checkout context, and order/session stitching. That means the reporting should distinguish: - **AI-referred visits** — visitors arrived from recognizable AI assistants, AI search sources, or AI-attributed campaign links. - **AI-assisted purchases** — purchase events preserved AI-attribution evidence through checkout or order context. - **Possible agentic checkouts** — checkout-like flows showed agentic commerce signals, but need stronger evidence before treating as confirmed. The caveat belongs in the product, not only in the footnotes: not every AI-assisted shopper or order can be identified. That is the right tradeoff. Merchants need useful measurement, but they also need trustworthy measurement. ## What merchants should do now You do not need to rebuild your store for AI commerce tomorrow. You should start with the basics that make your products understandable and measurable: 1. Audit your top products first. 2. Fix vague titles, descriptions, variants, and missing identifiers. 3. Validate Product JSON-LD and offer data. 4. Make shipping, returns, warranty, sizing, and compatibility easy to answer. 5. Create or improve AI discovery files with useful links and concise context. 6. Define UTM and agent-parameter conventions for AI partners. 7. Start measuring AI-referred sessions and AI-assisted orders where reliable source signals exist. At Honeybound, we are adding **AI Commerce Readiness** to Shopify audits: product data, structured data, policy clarity, AI discovery files, and attribution gaps. For Eventabee, the product opportunity is **AI Commerce Attribution**: showing when identifiable AI assistants, answer engines, and agentic checkout handoffs drive traffic and revenue. The strategy is simple: > Prepare for AI commerce, then prove what it drives. If you want to know whether your Shopify store is ready for AI commerce, run an [AI Commerce Readiness Audit](/shopify-ai-commerce-readiness). If you want to measure what AI-driven discovery turns into, Eventabee is building toward the attribution layer for that next channel. ## Sources - Shopify Engineering: [Building the Universal Commerce Protocol](https://shopify.engineering/ucp) - Shopify Dev Docs: [Agentic commerce](https://shopify.dev/docs/agents) - Shopify: [Universal Commerce Protocol](https://www.shopify.com/ucp) - Shopify News: [The agentic commerce platform](https://www.shopify.com/news/ai-commerce-at-scale) - Shopify Blog: [Agentic Commerce on Shopify: How It Works](https://www.shopify.com/blog/how-agentic-commerce-works) ## Key takeaways - UCP makes agentic commerce more practical, but it does not remove the need for clean product data, schema, policies, and FAQs. - Merchant attribution should distinguish confirmed AI referrers, AI-assisted orders, and possible agentic handoffs instead of labeling all direct traffic as AI. - Public Shopify docs show agent profiles and UCP negotiation with Shopify, but merchant apps should not assume every order webhook contains UCP agent identity. - The practical near-term standard is: prepare for AI commerce, then prove what detectable AI signals actually drive. ## FAQ ### Can Shopify merchants automatically see every UCP-driven order? Not necessarily. Shopify docs describe agent profiles, negotiation, checkout handoff, and order flows, and Shopify says AI-channel attribution appears in Shopify Admin. Public docs do not guarantee that every standard merchant app webhook includes UCP agent profile metadata, so app-level reporting should rely on detectable referrers, UTMs, source fields, cart or checkout stitching, and any future Shopify-exposed metadata. ### What should merchants do first for AI commerce readiness? Start with top products: clear titles, concrete descriptions, accurate variants, identifiers where relevant, valid Product JSON-LD, complete shipping and return policies, useful FAQs, and accessible discovery files like sitemaps or llms.txt where appropriate. ### How should AI agents preserve attribution? When an agent or partner sends a buyer to cart or checkout, it should append explicit parameters such as utm_source, utm_medium=ai_agent, utm_campaign, eb_agent, and an opaque eb_agent_session so the merchant has a better chance of connecting discovery to checkout and order outcomes. --- title: Shopify Order.cartToken in GraphQL: why it matters for post-checkout attribution url: https://honeybound.co/blog/shopify-order-carttoken-graphql-attribution date: 2026-05-18 summary: Shopify's 2026-07 Admin GraphQL API adds Order.cartToken. Here's why that small field matters for cart-to-order stitching, pixel + webhook dedupe, and server-side tracking on Shopify. tldr: Shopify added cartToken to the Admin GraphQL Order object in API 2026-07. Server-side tracking apps can now recover the cart token from order-only contexts and use it as an internal join key back to pre-purchase browser/session context. tags: shopify, eventabee, server-side-tracking, attribution, analytics --- ## Quick answer Shopify added `cartToken` to the Admin GraphQL `Order` object in API `2026-07`. That sounds small, but it fixes a real attribution gap: after checkout, apps often have an order webhook or order-status context, but not the original cart object. `Order.cartToken` gives tracking systems a better internal join key for connecting: ```text visitor → cart → checkout → order → conversion event ``` For Shopify merchants, the practical outcome is cleaner server-side tracking: stronger pixel + webhook dedupe, fewer orphaned purchase events, and more useful debugging when browser context is missing. ## What Shopify changed On May 12, 2026, Shopify announced that [`cartToken` is available on the Admin GraphQL `Order` object](https://shopify.dev/changelog/new-field-carttoken-added-to-the-order-graphql-admin-api). Shopify describes it as the token associated with the cart used to create the order, matching the existing REST Admin API `cart_token` field. The GraphQL shape is simple: ```graphql query EventabeeOrderCartToken($id: ID!) { order(id: $id) { id cartToken } } ``` If an app already knows the order ID, it can request the cart token without needing the cart object to still be present in the checkout/browser surface. ## The post-checkout attribution problem A Shopify purchase can reach a tracking app through several paths: - the web pixel sees browser-side checkout events; - Shopify sends `orders/create` webhooks; - thank-you and order-status surfaces expose order context; - ad platforms need a deduped purchase event with as much consent-safe context as possible. The hard part is that these surfaces do not all carry the same identifiers. Browser-side events can carry cookies, click IDs, user agent, page URL, and a session ID. Server-side webhooks carry reliable order/customer data, but they may arrive without the browser context that made the conversion attributable. Without a durable bridge, you can end up with a purchase event that is technically correct but hard to connect back to the visit, cart, campaign, or session that produced it. ## Why the cart token is useful The cart token is useful because it sits between browser behavior and the final order. A tracking system can: 1. capture the cart token before or during checkout when Shopify exposes it; 2. map that cart token to the browser/session context already collected with consent; 3. receive an order webhook after checkout; 4. fetch `Order.cartToken` if the webhook payload does not include a cart token; 5. stitch the order back to the session using the cart token mapping. That creates a deterministic order-to-cart join. It is not probabilistic fingerprinting. It is not a replacement for event IDs. It is another first-party Shopify key that can make post-checkout stitching less fragile. ## What this improves ### Pixel + webhook dedupe Most serious Shopify tracking setups use both browser-side and server-side purchase signals. The browser pixel can include click/browser context. The webhook is more reliable when the browser is blocked, slow, or missing. A cart-token bridge helps decide whether those signals describe the same purchase journey, especially when one side is missing fields. ### Server-side conversion recovery When the browser event fails but the order webhook arrives, the webhook can still become a useful server-side conversion event. If `Order.cartToken` reconnects it to a known cart/session, the tracking app can recover more context instead of treating the order as server-only and anonymous. ### Better debugging Attribution bugs are often stitching bugs: - the order exists, but the browser context disappeared; - the purchase was counted twice; - the webhook arrived, but the pixel did not; - a destination accepted the event, but with poor match quality. A first-class cart-token join gives support and analytics teams another concrete diagnostic: was this order connected by event ID, cart token, email/session mapping, or not at all? ## How Eventabee is using the pattern Eventabee already treats Shopify purchase tracking as a two-sided problem: browser events and Shopify webhooks should meet before the event is sent onward. The implementation pattern we are adding is intentionally conservative: - keep capturing browser/session context from the pixel; - store a cart-token-to-session mapping when the cart token is available; - when an order webhook lacks `cart_token`, fetch `Order.cartToken` from Admin GraphQL best-effort; - inject the token into Eventabee's internal payload before session enrichment and pixel + webhook merge; - cache positive lookups briefly so webhook retries do not hammer Shopify; - never fail webhook ingestion just because GraphQL enrichment fails. The next merchant-facing layer is stitch-rate reporting: showing whether a purchase was connected through pixel + webhook match, cart-token stitch, email/session mapping, or remained unstitched. That matters because “server-side tracking” is too vague. Merchants need to know where tracking recovered usable context and where it remained a backup conversion. ## Limits and privacy notes `Order.cartToken` is useful, but it should be handled carefully. - It does not replace consent. - It does not mean every historical order will have a useful token. - It depends on Admin GraphQL API `2026-07` or newer. - It should be treated as an internal join key, not a public customer identifier. - It should not be sent to ad platforms by default. The right use is internal stitching, diagnostics, and reporting. The destination payload should still use the identifiers and event fields each platform expects, filtered through the merchant's consent configuration. ## A practical implementation checklist For Shopify teams building this directly, the pattern is: 1. Capture cart token when available in browser/pixel events. 2. Store `cart_token → session_id` for a bounded TTL. 3. Build purchase event IDs that let pixel and webhook events dedupe. 4. On `orders/create`, keep any payload `cart_token` that already exists. 5. If it is missing, query Admin GraphQL `Order.cartToken` best-effort. 6. Inject the token before session enrichment and event merge. 7. Cache successful lookups and short negative results. 8. Track the stitch method (`event_id`, `cart_token`, `email`, or `none`) so reporting can explain what happened. That last point is the one merchants will feel: fewer black-box numbers, more visible tracking quality. ## Bottom line `Order.cartToken` is not a flashy API addition. It is exactly the kind of small platform field that makes attribution systems more reliable. If you run Shopify acquisition at scale, the question is not just “did the purchase event fire?” It is: - did the browser and server events match? - did the order reconnect to the session? - did the event carry the right consent-safe context? - can your team see why a conversion was stitched or not? That is the direction Shopify tracking needs to move: less hand-wavy “accuracy,” more explainable conversion recovery. [Eventabee](/work/eventabee) is built around that standard: consent-aware server-side tracking, pixel + webhook merging, and attribution diagnostics for Shopify merchants who need to know what their conversion data is actually doing. ## FAQ ### What did Shopify change? Shopify added `cartToken` to the Admin GraphQL `Order` object in API `2026-07`. The field returns the token associated with the cart that created the order, matching the existing REST Admin API `cart_token` field. ### Why does Order.cartToken matter for attribution? After checkout, many app surfaces have order context but not the original cart object. `Order.cartToken` gives apps a deterministic cart-to-order join key that can reconnect server-side order data to pre-purchase browser/session context. ### Does this replace consent? No. Cart-token stitching does not bypass consent or destination rules. It is an internal enrichment key that should still be applied only within the merchant's consent and privacy configuration. ### Should cart tokens be sent to Meta, Google, or TikTok? Usually no. Treat cart tokens as internal join keys for stitching, diagnostics, and reporting. Send only the destination-supported identifiers and fields that are appropriate for the merchant's consent state. ## Key takeaways Order.cartToken gives apps a cleaner bridge from an order webhook back to the cart/session that produced it. The practical win is better pixel + webhook dedupe, post-checkout attribution recovery, and debugging when browser context disappears. Cart tokens should stay internal: useful for stitching, not a field to spray into ad-platform payloads. Consent still applies; this improves attribution plumbing, not privacy requirements. ## FAQ ### What did Shopify change? Shopify added cartToken to the Admin GraphQL Order object in API 2026-07. The field returns the token associated with the cart that created the order, matching the existing REST Admin API cart_token field. ### Why does Order.cartToken matter for attribution? After checkout, many app surfaces have order context but not the original cart object. Order.cartToken gives apps a deterministic cart-to-order join key that can reconnect server-side order data to pre-purchase browser/session context. ### Does this replace consent? No. Cart-token stitching does not bypass consent or destination rules. It is an internal enrichment key that should still be applied only within the merchant's consent and privacy configuration. ### Should cart tokens be sent to Meta, Google, or TikTok? Usually no. Treat cart tokens as internal join keys for stitching, diagnostics, and reporting. Send only the destination-supported identifiers and fields that are appropriate for the merchant's consent state. --- title: How to Optimize Shopify llms.txt and agents.md for AI Search and Shopping Agents url: https://honeybound.co/blog/shopify-llms-txt-agents-md-optimization date: 2026-05-16 summary: A practical Shopify merchant guide to improving `llms.txt` and `agents.md` for AI search, LLM answers, product discovery, and shopping agents without treating the files as ranking hacks. tldr: This is the hands-on optimization guide. Use it after reading the Shopify auto-generation context page. The goal is not a longer file; it is a clearer machine-readable merchandising layer that points AI systems to truthful, crawlable product, policy, collection, and checkout evidence. tags: shopify, ai-search, llms-txt, agents-md, geo, seo --- Shopify's new root-level AI files are an opportunity, but they are easy to misunderstand. `/llms.txt` and `/agents.md` are not magic buttons that make a store rank first in ChatGPT, Perplexity, Claude, Gemini, or Google AI Overviews. They are closer to machine-readable merchandising notes: short, structured files that help crawlers and shopping agents understand what your store sells, what pages matter, what policies should be respected, and which endpoints are available for product discovery. If you missed the rollout details, start with our earlier breakdown: [Shopify llms.txt and agents.md: what gets auto-generated, and how to override it](https://honeybound.co/blog/shopify-llms-txt-agents-md). This follow-up is about optimization: what to put in these files, how to align them with SEO and GEO, and how different categories of Shopify stores should tune the content. ## Quick answer: the best Shopify llms.txt is a concise, truthful store brief For SEO and GEO, the goal is not to stuff keywords into a text file. The goal is to make the store easier for machines to summarize correctly. A strong Shopify `llms.txt` should: - identify the canonical store, brand, audience, and product category in the first few lines; - point agents to the most useful crawlable pages: collections, best sellers, buying guides, FAQs, policies, reviews, and sitemap files; - explain product selection signals such as size, material, use case, compatibility, dietary preference, skin concern, fit, replenishment cycle, or price tier; - avoid unverifiable claims that are not visible on the storefront; - avoid hiding critical merchandising facts only in `llms.txt`; and - stay consistent with product structured data, collection copy, merchant policies, reviews, and inventory state. A strong `agents.md` should do a different job. It should tell a shopping agent how to behave: search first, compare relevant options, respect availability and shipping limits, confirm size/variant requirements, cite policy pages when discussing returns or subscriptions, and send shoppers to Shopify checkout rather than inventing an order flow. ## What Shopify's own materials imply Shopify's public developer materials point in the same direction: agents need structured commerce access, not just a text file. Shopify's Storefront MCP documentation describes store-specific MCP endpoints that let agents browse products, manage carts, answer policy questions, and check out from a selected merchant. Shopify separates standard Storefront MCP tools at: ```text https://{shop}.myshopify.com/api/mcp ``` from UCP catalog tools at: ```text https://{shop}.myshopify.com/api/ucp/mcp ``` The catalog tools include `search_catalog`, `lookup_catalog`, and `get_product`. Shopify's docs also state that the Storefront MCP catalog tools conform to the Universal Commerce Protocol catalog capability. That matters because `llms.txt` should not pretend to be the full catalog API. It should help agents find and use the right sources. For the related discovery file, the earlier post also covers [how `/sitemap_agentic_discovery.xml` points agents toward `/llms.txt`, `/llms-full.txt`, and `/agents.md`](https://honeybound.co/blog/shopify-llms-txt-agents-md#what-shopify-is-auto-generating). Shopify's "Build a Storefront AI agent" documentation frames the practical use case clearly: an AI shopping assistant can help shoppers search for products, get recommendations, ask questions about products and policies, manage carts, and complete checkout in natural language. That means your optimization work needs to help agents answer real shopping questions, not merely announce that an `llms.txt` file exists. Shopify's developer changelog also shows two important platform directions: - Storefront Catalog MCP implementing UCP catalog capability. - Stricter rate limits for bots and agents, with Web Bot Auth recommended for bot operators that need higher rate limits. The takeaway for merchants: make the public store understandable, keep agent-accessible surfaces efficient, and expect serious agent traffic to care about protocol, rate limits, and quality signals. ## What Shopify support/community guidance says about implementation The Shopify Developer Community has become the most practical source for early implementation details. In a thread about `llms.txt` and `agents.md`, merchants reported that Shopify now serves `/llms.txt` and `/agents.md` natively. One reported workaround was confirmed by another user: ```text templates/llms.txt.liquid ``` Adding that file to the theme can override Shopify's generated `/llms.txt`, similar to Shopify's `robots.txt.liquid` pattern. Two caveats matter: 1. Older Shopify URL redirects for `/llms.txt` may no longer be honored once Shopify serves the route natively. 2. An equivalent confirmed customization hook for `/agents.md` was not identified in that thread. Another Shopify community discussion is useful for avoiding a common mistake: simply uploading an `llms.txt` file to Shopify Files or a CDN URL is not the same as serving it from the store root. If the file lives at `cdn.shopify.com/...`, crawlers checking `https://yourstore.com/llms.txt` will not necessarily treat it as your root-level agent brief. ## SEO and GEO principles for Shopify AI files Search engine optimization and generative engine optimization are different, but they overlap. The same messy store architecture that hurts Google often hurts AI answers too. ### 1. Treat the file as a routing layer, not the source of truth `llms.txt` should point to canonical sources: - collection pages; - product pages; - comparison pages; - size guides; - policy pages; - FAQs; - buying guides; - sitemap files; and - Storefront MCP/UCP endpoints where available. Do not write claims in `llms.txt` that cannot be verified on the storefront. If the file says "best waterproof boots for winter hiking" but the collection page has no waterproof materials, reviews, use-case copy, schema, or product details, AI systems have no reason to trust the file. ### 2. Make the first 100 words answer the entity question Agents need to know what the store is. Weak: ```text # Acme Store Welcome to our online shop. ``` Strong: ```text # Acme Trail Supply Acme Trail Supply is a US-based Shopify store selling waterproof hiking boots, trail socks, repair kits, and cold-weather hiking accessories for day hikers, backpackers, and outdoor workers. ``` That opening gives a model entities, audience, category, geography, and product scope. ### 3. Use query-matching collection language without keyword stuffing Use language that matches how customers ask questions: - "wide-fit women's running shoes"; - "fragrance-free moisturizer for sensitive skin"; - "high-protein vegan snacks"; - "replacement filters for Model X"; - "wedding guest dresses under $200"; - "B2B bulk coffee subscriptions". Do not repeat the same phrase ten times. Give agents a clean map of use cases and relevant URLs. ### 4. Make policy interpretation safe Agents will answer questions like: - "Can I return sale items?" - "Does this ship to Canada?" - "Is this subscription easy to cancel?" - "Are duties included?" - "Is this product vegan?" Your files should instruct agents to cite the live policy page and avoid making promises beyond it. ### 5. Include markdown alternatives when available If your site exposes markdown versions of key pages, list them. Markdown is easier and cheaper for models to parse than heavy HTML. If you do not have markdown routes, keep the HTML clean and make sure product JSON-LD, collection copy, breadcrumbs, FAQ schema, and internal links are in place. ### 6. Test with real prompts After updating the file, test prompts like: - "What does [brand] sell?" - "Which [brand] product is best for [use case]?" - "Compare [brand] to [competitor/category]." - "Can I return [brand] products?" - "Find me a [product category] from [brand] under $X." Save before/after outputs. The goal is not vanity. The goal is fewer hallucinations, better product routing, and higher-quality citations. ## Recommended llms.txt structure for Shopify Use this as a baseline. If you need the implementation steps, the companion post explains the current Shopify theme override path: [how to edit Shopify's `/llms.txt` file with `templates/llms.txt.liquid`](https://honeybound.co/blog/shopify-llms-txt-agents-md#how-to-override-shopifys-llmstxt). ```markdown # {{ shop.name }} {{ shop.name }} is a {{ geography }} Shopify store selling {{ primary category }} for {{ target customers }}. Use this file to understand the store, then verify product, price, inventory, shipping, return, and subscription details on the linked canonical pages before answering shoppers. ## Canonical store - Storefront: https://example.com - Sitemap: https://example.com/sitemap.xml - Agentic discovery sitemap: https://example.com/sitemap_agentic_discovery.xml - Product catalog search: https://example.myshopify.com/api/ucp/mcp - Storefront MCP: https://example.myshopify.com/api/mcp ## What we sell - Category 1: short description and collection URL - Category 2: short description and collection URL - Category 3: short description and collection URL ## Best entry points for shoppers - Best sellers: https://example.com/collections/best-sellers - New arrivals: https://example.com/collections/new-arrivals - Buying guide: https://example.com/pages/buying-guide - Size guide: https://example.com/pages/size-guide - Reviews: https://example.com/pages/reviews ## Policies agents should verify - Shipping: https://example.com/policies/shipping-policy - Returns: https://example.com/policies/refund-policy - Privacy: https://example.com/policies/privacy-policy - Terms: https://example.com/policies/terms-of-service ## Guidance for AI systems - Prefer canonical product and collection URLs. - Do not claim inventory, price, discounts, shipping time, medical benefit, or compatibility unless it is present on the linked live page or returned by an authorized commerce endpoint. - When recommending a product, mention the use case, relevant variants, and the canonical product URL. - When answering policy questions, cite the relevant policy page. ``` ## Recommended agents.md structure for Shopify If your store exposes or can customize `agents.md`, use it as a behavior file. For current Shopify behavior and caveats, see the companion explainer: [what `/agents.md` is and why Shopify may own that route today](https://honeybound.co/blog/shopify-llms-txt-agents-md#what-about-agentsmd). ```markdown # Agent instructions for {{ shop.name }} You are helping a shopper understand and buy products from {{ shop.name }}. Prioritize accurate product fit, transparent policies, and checkout safety. ## Commerce tools - Search catalog using Storefront UCP/MCP where available. - Use product pages as the fallback source of truth. - Use Shopify checkout for purchases. Do not collect payment details in chat. ## Product recommendation rules 1. Ask one clarifying question when size, compatibility, skin type, dietary need, use case, budget, or urgency materially changes the recommendation. 2. Compare at most 3-5 products unless the shopper asks for a larger list. 3. Prefer in-stock products and explain variant differences. 4. Mention price and promotions only after verifying the live product page or commerce endpoint. 5. Link to canonical product or collection URLs. ## Policy rules - For returns, subscriptions, delivery, warranties, allergens, ingredient claims, age restrictions, and regional availability, cite the relevant store policy. - If a question requires customer-specific information, direct the shopper to customer support or account checkout rather than guessing. ## Do not - Invent discounts. - Promise delivery dates not shown by checkout or policy pages. - Recommend restricted products to restricted regions. - Treat old cached content as current inventory. ``` ## Category-specific optimization examples The best files are category-aware. A fashion brand, skincare brand, food brand, and B2B parts store should not use the same instructions. ### Apparel and footwear stores Optimize around fit, variant selection, material, occasion, and return policy. ```markdown ## What we sell - Women's linen dresses for warm-weather travel and events: /collections/linen-dresses - Wide-fit leather boots in half sizes: /collections/wide-fit-boots - Petite and tall sizing edits: /collections/petite and /collections/tall ## Fit and variant guidance - Always ask for size, height, fit preference, and intended use before making a final recommendation. - Use the size guide at /pages/size-guide before answering fit questions. - For footwear, clarify width, arch support needs, and whether the shopper plans to wear thick socks. - For eventwear, consider dress code, weather, and return window. ``` SEO/GEO pages to support this file: - size guide with schema; - collection copy for fit/use cases; - review snippets that mention fit; - product details for fabric, care, model sizing, and measurements; - FAQ for returns, exchanges, and final sale. ### Beauty, skincare, and wellness stores Optimize around ingredients, skin concerns, contraindications, routine order, and claims safety. ```markdown ## What we sell - Fragrance-free skincare for sensitive skin: /collections/sensitive-skin - Mineral SPF for daily use: /collections/mineral-sunscreen - Refillable body care: /collections/refills ## Ingredient and claim guidance - Do not make medical claims. - For pregnancy, allergy, medication, or medical-condition questions, advise the shopper to consult a qualified professional. - Recommend products by skin concern, ingredient preference, and routine step. - Cite ingredient pages and product pages when discussing actives. ``` SEO/GEO pages to support this file: - ingredient glossary; - routine builder; - product pages with complete INCI/ingredient lists; - FAQs for sensitive skin, fragrance, SPF, refills, and returns; - review content organized by concern. ### Food, beverage, and supplement stores Optimize around dietary restrictions, allergens, subscriptions, bundles, shipping temperature, and compliance. ```markdown ## What we sell - Single-origin coffee subscriptions: /collections/subscriptions - High-protein vegan snacks: /collections/vegan-protein-snacks - Gluten-free pantry bundles: /collections/gluten-free ## Dietary and subscription guidance - Always verify allergens and ingredients on the current product page. - Do not claim a product is allergen-free unless the product page says so. - For subscriptions, cite cancellation, skip, and billing policies. - For perishable products, verify shipping regions and temperature handling. ``` SEO/GEO pages to support this file: - allergen and ingredient tables; - subscription policy page; - shipping region page; - bundle comparison pages; - FAQs for freshness, storage, and cancellation. ### Home goods, furniture, and decor stores Optimize around dimensions, materials, room use, delivery constraints, assembly, and returns. ```markdown ## What we sell - Small-space modular sofas: /collections/modular-sofas - Solid wood dining tables: /collections/dining-tables - Machine-washable rugs: /collections/washable-rugs ## Recommendation guidance - Ask for room dimensions, household constraints, material preference, and budget. - Cite product dimensions and care instructions. - For freight items, verify delivery method, return window, and assembly needs. - Do not imply a product will fit unless dimensions are checked. ``` SEO/GEO pages to support this file: - dimension-rich product pages; - room guides; - material and care guides; - delivery and assembly policy pages; - comparison content by room size and budget. ### B2B, parts, industrial, and compatibility-heavy stores Optimize around model numbers, compatibility, technical specs, warranty, quote workflows, and support escalation. ```markdown ## What we sell - Replacement filters for Model X and Model Y systems: /collections/replacement-filters - Commercial coffee machine parts: /collections/commercial-espresso-parts - Bulk maintenance kits: /collections/maintenance-kits ## Compatibility guidance - Ask for brand, model number, serial number, region, and installation context. - Do not assert compatibility unless it appears in the product specs or compatibility table. - If compatibility is uncertain, direct the shopper to support with the model number before purchase. - For bulk or tax-exempt orders, route to the quote/contact workflow. ``` SEO/GEO pages to support this file: - compatibility tables; - PDF/manual pages with text equivalents; - model-number landing pages; - technical spec schema; - support escalation and quote request pages. ## An optimization checklist for Shopify merchants Before you publish a custom `llms.txt`, check the basics. ### Storefront source of truth - Product titles are descriptive without being spammy. - Product descriptions include use case, specs, materials/ingredients, sizing, compatibility, and care where relevant. - Collection pages have useful intro copy and internal links. - Policy pages are complete and crawlable. - Sitemap files are accessible. - Structured data is valid on product, article, FAQ, and breadcrumb surfaces. ### Agent file quality - The first paragraph clearly states what the store sells and who it serves. - Canonical URLs use the primary domain, not duplicate preview or CDN URLs. - Top collections and guides are prioritized. - Policy pages are linked. - MCP/UCP endpoints are listed only if they work for the store. - The file tells agents what not to infer. - The file is short enough to be useful. ### GEO answer readiness - The store has a direct-answer FAQ for common purchase questions. - Buying guides answer comparison prompts. - Category pages match natural-language shopping queries. - Product pages have enough attributes for recommendations. - Reviews and testimonials are crawlable where possible. - The brand has consistent entity signals across the store, social profiles, app listings, and support pages. ### Measurement - Log before/after AI answers for core queries. - Track referral traffic from AI search and assistant surfaces where possible. - Watch Google Search Console for emerging query impressions around AI, category, and comparison terms. - Monitor crawl behavior and server load from bots/agents. - Re-test after major catalog, policy, or theme changes. ## Common mistakes ### Mistake 1: Treating llms.txt as a keyword dump A model does not need fifty repetitions of "best Shopify shoes". It needs a trustworthy map. ### Mistake 2: Linking only to products Agents also need buying guides, policies, FAQs, reviews, sizing pages, and support paths. ### Mistake 3: Using a CDN URL instead of the root file A Shopify Files URL is not the same as `https://yourstore.com/llms.txt`. ### Mistake 4: Assuming agents.md is customizable everywhere `llms.txt` has a reported theme-template override path. `agents.md` customization should be tested store-by-store until Shopify documents a supported equivalent. ### Mistake 5: Making claims the storefront cannot prove If you want AI systems to recommend your "best trail running shoes for wide feet," create the collection, add the product attributes, write the buying guide, mark up the FAQ, and then point `llms.txt` to those pages. ## A high-performing Shopify AI-search workflow Here is the workflow we recommend for serious stores: 1. **Audit the generated files.** Fetch `/llms.txt`, `/agents.md`, and any agentic discovery sitemap on the live store. 2. **Map high-intent prompts.** List the questions shoppers ask before they buy. 3. **Fix storefront content first.** Improve collection copy, product specs, FAQ, policy clarity, schema, and internal links. 4. **Create or update `templates/llms.txt.liquid`.** Keep it concise, category-aware, and URL-focused. 5. **Test root delivery.** Confirm `https://yourstore.com/llms.txt` returns the expected content and content type. 6. **Validate agent behavior.** Test prompts in AI search/chat tools and with any Storefront MCP agent implementation. 7. **Measure and iterate.** Revisit monthly or when catalog/policy changes are significant. ## Final recommendation The stores that win in AI search will not be the ones that add the longest `llms.txt` file. They will be the stores with the clearest machine-readable merchandising system. Use `llms.txt` to route agents to the right evidence. Use `agents.md` to guide safe shopping behavior where you can. Use Shopify's Storefront MCP and UCP capabilities when an agent needs live catalog and cart access. And keep the old SEO fundamentals strong: fast pages, clean architecture, useful collection copy, specific product attributes, policy clarity, internal links, structured data, and credible content. AI systems are becoming another storefront interface. Give them the same quality of merchandising you would give a human shopper. ## Key takeaways - Treat this as the practical optimization pillar for Shopify AI-search files. - Keep the auto-generation/context article as the supporting page. - Add merchant-specific product, collection, policy, and buying-guide links. - Do not make claims in `llms.txt` that the storefront cannot support. - Verify root-level serving, canonical URLs, structured data, and policy consistency after publishing. ## FAQ ### Is llms.txt a ranking hack? No. Treat it as machine-readable merchandising and routing guidance. It should point AI systems toward truthful storefront evidence, not make unsupported ranking claims. ### What should Shopify merchants optimize first? Start with canonical collection, product, policy, FAQ, buying-guide, sitemap, and agent-discovery links. Keep the file short enough to be useful. ### How does this guide relate to the Shopify auto-generation article? The auto-generation article explains what Shopify may already expose and what override risks exist. This guide is the practical checklist for improving the merchant-authored layer. --- title: Shopify llms.txt and agents.md: what gets auto-generated, and how to override it url: https://honeybound.co/blog/shopify-llms-txt-agents-md date: 2026-05-15 summary: Shopify is testing default `llms.txt`, `agents.md`, and agentic discovery files. This context page explains what Shopify generates, what merchants risk when overriding it, and why the safest override preserves agent discovery links. tldr: This is the context page: what Shopify auto-generates, what gets replaced when a merchant adds `templates/llms.txt.liquid`, and which generated agent-discovery links should usually be preserved. For the hands-on optimization checklist, use the optimization guide. tags: shopify, ai-search, agentic-commerce, seo --- Shopify is starting to expose a new set of machine-readable storefront files: - `/llms.txt` - `/agents.md` - `/sitemap_agentic_discovery.xml` The current behavior is clear enough to plan around: Shopify appears to be testing a native `llms.txt` file for storefronts, and if a merchant creates `templates/llms.txt.liquid` in the theme, that file can replace Shopify's default response. The more important version: this is not just another SEO text file. Shopify's default file points AI crawlers and commerce agents toward the store's search, catalog, sitemap, Universal Commerce Protocol discovery, and MCP endpoint. If you override it casually, you may remove the exact agent-discovery hooks Shopify is experimenting with. ## What Shopify is auto-generating On stores where the test is active, `/llms.txt` looks like a compact map for AI systems. The default response commonly includes: - Store name and short description - Browse links such as `/collections/all` - Search pattern such as `/search?q={query}` - Store contact and currency information - A **For Agents & Developers** section - Link to `/agents.md` - Link to `/.well-known/ucp` - Link to `/api/ucp/mcp` - Link to `/sitemap.xml` - Shopify platform attribution The companion `/agents.md` is more operational. It explains how an agent should interact with the store, including discovery, product search, cart or checkout flow, and human-approval expectations around payment. The third file, `/sitemap_agentic_discovery.xml`, acts like a mini sitemap for agent-oriented resources. In observed storefronts it points to `/llms.txt`, `/llms-full.txt`, and `/agents.md`. That matters because an AI system may not begin with your visual storefront. It may first ask: "What files does this merchant expose for agents?" Shopify is testing an answer. ## Why the default llms.txt is thin The generated file is useful, but it is intentionally generic. It does not know your highest-margin collections, your product education pages, your shipping constraints, your support policies, or the pages that best explain why a buyer should trust you. A stronger merchant-authored `llms.txt` might point to: - Top category and collection pages - Buying guides - FAQ and policy pages - Fit, sizing, warranty, or ingredient explainers - Storefront search syntax - Best canonical URLs for products and collections - Content that answers common pre-purchase questions That does not mean every merchant should rewrite the file today. It means Shopify's default is a baseline, not a content strategy. ## How to override Shopify's llms.txt The current override path is theme-based: 1. Open the Shopify theme code editor. 2. Go to the `Templates` directory. 3. Create a new file named `llms.txt.liquid`. 4. Add the content you want served at `/llms.txt`. 5. Save and verify the live `/llms.txt` URL. If you work in a theme repository, the file path is usually: ```text templates/llms.txt.liquid ``` The important detail is that this is an override. Shopify does not merge your additions into the generated file. Once the template exists, your theme owns the response. So do not create an empty file. Do not paste a generic AI prompt. Do not remove the agent/developer section unless you understand what you are removing. ## A safer override template If you decide to customize the file, start by preserving the useful Shopify-generated pieces and adding merchant-specific discovery links above them. ```liquid # {{ shop.name }} > Short, factual description of the store and what customers can buy here. {{ shop.name }} is an online store at {{ shop.url }}, powered by Shopify. ## Recommended pages - Homepage: {{ shop.url }} - All products: {{ shop.url }}/collections/all - Search: {{ shop.url }}/search?q={query} - Contact: {{ shop.url }}/pages/contact - Shipping policy: {{ shop.url }}/policies/shipping-policy - Refund policy: {{ shop.url }}/policies/refund-policy - Privacy policy: {{ shop.url }}/policies/privacy-policy ## Collections - Main collection: {{ shop.url }}/collections/all - Add your most important collection URLs here. ## Buying guidance - Add links to sizing, fit, compatibility, ingredients, warranty, or FAQ pages. - Prefer canonical URLs that answer real buyer questions. ## Store information - Currency: {{ cart.currency.iso_code | default: shop.currency }} - Contact: add your public support email or contact page ## For Agents & Developers This store may support agent-oriented commerce discovery through Shopify. - Agent instructions: {{ shop.url }}/agents.md - UCP discovery: {{ shop.url }}/.well-known/ucp - MCP endpoint: {{ shop.url }}/api/ucp/mcp - Sitemap: {{ shop.url }}/sitemap.xml ## Platform This store is built on Shopify (https://www.shopify.com). ``` Treat that as a starting point, not a universal answer. If the store does not expose a page, remove it. If your best buyer education lives somewhere else, link that instead. ## What not to put in llms.txt A good `llms.txt` should help machines find accurate public information. It should not be a dumping ground for private instructions or speculative SEO copy. Avoid: - Discount codes you do not want broadly surfaced - Internal fulfillment rules - Private supplier or margin details - Claims that are not present on public pages - Long keyword blocks - Instructions that conflict with policies, product pages, or checkout behavior Think of the file as a map. If the map points to weak or contradictory content, it does not make the store more understandable. ## What about agents.md? Right now, `agents.md` appears to be Shopify-owned on stores where the test is active. The content is focused on agent behavior: how to discover commerce capabilities, what endpoints exist, what read-only product routes are available, and why payment should require human approval. Merchants should read it because it reveals Shopify's direction: storefronts are being prepared for agents that can browse, compare, cart, and start checkout flows. But the practical merchant lever today is still `llms.txt`. That is the file merchants can currently override through the theme. ## Should merchants do this now? For most stores: not urgently. There is no public proof that `llms.txt` materially improves AI search visibility. There is also no stable Shopify documentation explaining the final intended merchant workflow. This is early. The stores that should consider a careful override are the ones where the default file is obviously incomplete for agent discovery: large catalogs, complex buying criteria, important policy pages, or high-value guides that a generic Shopify file will never know to include. Even then, the right move is conservative: 1. Fetch the current default `/llms.txt`. 2. Save a copy. 3. Add merchant-specific links. 4. Preserve Shopify's agent/developer links. 5. Publish the template. 6. Re-fetch `/llms.txt` and validate every URL. 7. Re-check after Shopify makes future changes. ## The real opportunity The file itself is not the strategy. The strategy is making your store easier for non-human readers to understand. That means clean product data, stable canonical URLs, useful collection pages, complete policy pages, structured data, and content that answers buyer questions directly. `llms.txt` can point to those assets, but it cannot invent them. Shopify adding these files by default is a signal. Agentic commerce is becoming part of the storefront surface area. The safest response is not panic, and it is not ignoring the feature. It is to document what Shopify generated, preserve the agent-discovery pieces, and only override when you can make the file more accurate than the default. ## Key takeaways - Treat this as the news/context article, not the full optimization guide. - Shopify-generated `llms.txt` can include useful agent discovery links. - A custom `templates/llms.txt.liquid` replaces Shopify output; it does not merge with it. - Preserve Storefront MCP/UCP/agent discovery links unless there is a reason to remove them. - Link readers to the optimization guide for templates, examples, and QA steps. ## FAQ ### Is this the optimization guide? No. This page explains what Shopify is auto-generating and what can go wrong when merchants override it. The optimization guide covers the practical checklist and templates. ### Does Shopify merge custom llms.txt content with its generated file? No. Based on current behavior, adding `templates/llms.txt.liquid` makes the theme own the response, so merchants should preserve useful generated discovery links manually. ### Should every Shopify merchant override llms.txt immediately? No. Merchants should first inspect the generated file, identify what is missing, and only override when they can preserve or improve the useful discovery information. --- title: Your storefront runs five tracking systems. It should run one. url: https://honeybound.co/blog/your-storefront-runs-five-tracking-systems date: 2026-05-13 summary: A Shopify tracking-consolidation argument for merchants running too many pixels, tags, scripts, and destination-specific snippets on the storefront. tldr: Five tracking systems usually means five chances for inconsistent consent, broken attribution, duplicate events, and slower storefronts. Consolidation should reduce script weight and make event routing easier to audit. tags: tracking, performance, data, ads --- Open the network tab on a mid-size DTC store. Count the outbound requests in the first three seconds of a product page load. You'll find Meta's `fbevents.js`, Google's `gtag.js`, TikTok's Pixel, Klaviyo's tracker, Pinterest, maybe Snap, usually a CDP or tag manager, almost always a separate consent banner from a seventh vendor, and a personalization tool for good measure. Each one is "lightweight." Each one's docs page says so. Stacked together, they cost conversions in three currencies, and most merchants only track one of them. ## The three currencies - **Render-blocking milliseconds.** Every synchronous script in the theme `` delays First Contentful Paint. Google's Core Web Vitals report notices. So does your conversion rate on a 200ms swing. - **Lost events.** Content blockers. ITP. Consent rejections. Every missed event is a conversion your ad platform thinks didn't happen — and optimizes against accordingly. - **Dirty data.** Meta sees `Purchase $49.99`. GA sees `purchase 4999` (cents). TikTok sees `CompletePayment` with the currency implied by the account region. Your attribution reports disagree by 8% and nobody can reproduce why. Consolidating tracking isn't a philosophical preference. It's how you move all three at once. ## Currency one — page speed The claim people expect here is: "install eventabee and your CWV score goes up." The honest answer is more interesting. eventabee's pixel ships as a Shopify **Web Pixel extension** — it runs in a sandboxed iframe, not in the main page context. By construction, it cannot block main-thread rendering. The theme embed that handles consent and identity loads with `defer`, so it runs after parsing, not during. Meta's `fbevents.js` does not do this. Klaviyo's tracker does not do this. Each of those cookie-sync requests, each of those synchronous DOM writes, each of those third-party TLS handshakes in the `` is a render-blocking event you're paying for on every page load. Here's the part most posts leave out: installing eventabee doesn't delete those tags. By default, it **coexists** with them — events from the browser pixel and events from eventabee's server-side fanout are deduplicated by shared `event_id`, so nothing breaks on day one. Which means the page-speed win is real, but it's **opt-in**. You have to delete the old tags yourself to collect it. That's a feature (no forced migration risk, no broken dashboards during the cutover) and a footnote you should know about before you benchmark. ## Currency two — ROAS This is the beat we've written about twice already, from different angles. Browser pixels miss 10–25% of events to blockers, ITP, and network failures. Server-side fanout from a first-party endpoint recovers them — the pipeline dedups against the browser event when both arrive, and delivers the one the browser silently dropped when only it arrives. ([Event loss is invisible →](/blog/event-loss-is-invisible)) Consent rejections are the other half of the same hole. 25–40% reject in regulated regions. If your banner vendor and your pipeline are separate systems, a consent upgrade on a return visit can't backfill the rejected window. Events from that window are gone. In the consolidated model, eventabee stores every event regardless of consent state and replays up to 30 days on consent upgrade — Business tier. ([Consent is a growth metric →](/blog/consent-is-a-growth-problem)) Two leaks. One pipe. Both recoverable. ## Currency three — the data itself The third currency is the one nobody puts on a scorecard. When five tools ingest the same event, they each normalize it differently. Meta wants `currency: "USD"`. GA wants currency in cents as part of a typed schema. TikTok wants top-level fields for e-commerce but nested for custom events. Some tools hash `email` before send; others hash it after. Country codes arrive as "US" or "USA" depending on which library wrote them. State fields arrive as "CA" or "California" depending on which theme. Event names come through as `Purchase`, `purchase`, or `complete_payment` — same event, three spellings. Your Meta dashboard says one number. Your GA dashboard says another. They are both "right." Nobody on the team can reproduce which one to trust, so nobody trusts either. A single pipe has a single normalize stage. One place extracts the currency from Shopify's nested `cost.totalAmount.currencyCode`. One place coerces every ID to a string so downstream type mismatches don't happen. One place runs `NormalizeCountry` and `NormalizeState` so "US" / "USA" / "United States" all land as `US`. One place synthesizes line items so a single-product event always has a `content_ids` array. Every destination receives the same canonical shape. The dashboards start agreeing. You start trusting the number enough to spend against it. ## When one pipe is wrong Consolidation isn't universal. Three cases where it's the wrong answer: - **You already run a mature CDP.** If Segment or Rudderstack is already your pipe, eventabee doesn't replace it — and shouldn't. Keep the CDP; send events through it. - **Regulated verticals on an existing TMS.** If you're on Tealium or Ensighten because compliance requires it, stay. The consolidation math doesn't include your audit overhead. - **Under ~$500k GMV.** The payoff from consolidating doesn't clear the switching cost at that stage. Run the browser pixels, tolerate the leaks, revisit when the numbers are big enough that 10–15% recovered conversions pays for an afternoon of theme cleanup. ## The umbrella We've written about pixel loss, about consent, and about secure merchant-defined destinations. Each of those is one currency. The reason the same app keeps showing up in those stories is that they all reduce to the same bottleneck: five browser-side systems pretending to be a tracking stack. [eventabee](/work/eventabee) is the version where they actually are one. ## Key takeaways - This is the tracking-consolidation spoke. - Link event-loss math to the pixel-loss pillar. - Treat performance, consent, and attribution as one system. - Consolidation should reduce duplicate events and script weight. - Verify destination outputs after removing tags. ## FAQ ### Why is running many tracking systems a problem? Multiple trackers add script weight, duplicate events, create inconsistent attribution, and make it harder to debug conversion data. ### What should replace fragmented storefront tracking? A unified first-party event pipeline can collect, normalize, and route events to the platforms that need them. ### Can consolidating tracking improve page speed? Yes. Reducing redundant browser scripts can lower storefront overhead and shift more work to controlled server-side infrastructure. --- title: Virginia, Colorado, Connecticut, Utah: Multi-State Shopify Privacy Compliance url: https://honeybound.co/blog/us-state-privacy-laws-shopify-matrix date: 2026-05-10 summary: A multi-state Shopify privacy matrix for comparing state-level consent, opt-out, GPC, and DSAR requirements. Use state-specific pages for implementation checklists. tldr: Use this page to compare state privacy patterns across jurisdictions. Use the Colorado checklist for CPA-specific implementation detail and DSAR pages for request workflows. tags: multi-state-compliance, eventabee, dsar-handling, consent-management --- ## Quick answer Use this page to compare state privacy patterns across Shopify stores. Use state-specific checklists, such as the [Colorado Privacy Act checklist](/blog/colorado-privacy-act-shopify-checklist), when you need implementation detail for one state. Most merchants need to track four operational areas: notice, opt-out or consent behavior, GPC handling, and DSAR workflow. ## Comparison matrix | Area | What changes by state | Shopify implementation concern | |---|---|---| | Notice | Required disclosures and rights language | Privacy policy and banner copy | | Opt-out | Scope and covered data uses | Category controls and destination routing | | GPC | Recognition requirements | Browser signal detection and storage | | DSARs | Timelines and request types | Intake, identity matching, export, review | | Sensitive data | Consent or processing limits | Category mapping and data minimization | ## How to use the matrix Start with the states where the store has customers, then map requirements to actual systems. A policy update is not enough if event destinations keep receiving data that should have been suppressed. ## Where this fits This is the cross-state comparison page. Use the [Colorado Privacy Act Shopify checklist](/blog/colorado-privacy-act-shopify-checklist) for Colorado-specific implementation detail. ## Key takeaways - This is the cross-state comparison matrix. - Keep Colorado implementation details on the Colorado checklist. - Separate consent display, GPC handling, and DSAR workflows. - Link legal specifics to current source material when refreshed. - Treat compliance scope as operational guidance, not legal advice. ## FAQ ### Does Eventabee support all US states? Eventabee supports 19 US states with privacy laws as of 2026, offering a unified approach to manage consent and DSARs from one dashboard. ### How does Eventabee handle DSAR requests? Eventabee offers manual review for basic bundles and automated responses based on confidence levels for more complex scenarios, ensuring compliance across multiple states. ### What is the pricing model of Eventabee? Eventabee's Pro tier costs $49/mo with flat pricing, providing comprehensive consent management and DSAR handling without metering by order volume or event count. --- title: Colorado Privacy Act Shopify Compliance Checklist (2026) url: https://honeybound.co/blog/colorado-privacy-act-shopify-checklist date: 2026-05-10 summary: A Colorado Privacy Act checklist for Shopify merchants: consent modes, GPC handling, DSAR process, data-routing proof, and when to escalate to legal review. tldr: Use this page for Colorado-specific CPA implementation questions. Use the multi-state privacy matrix when comparing Virginia, Colorado, Connecticut, Utah, and other state privacy obligations side by side. tags: colorado-privacy-act, shopify-compliance, eventabee, consent-management, dsar-support --- ## Quick answer Use this page for Colorado Privacy Act implementation checks on Shopify. Use the [multi-state privacy matrix](/blog/us-state-privacy-laws-shopify-matrix) when comparing Colorado against other states. For a Shopify merchant, the practical CPA work is consent and opt-out behavior, GPC handling, DSAR workflow, data-routing evidence, and policy review. Treat this as an operational checklist, not legal advice. ## Colorado checklist | Area | What to verify | |---|---| | Notice | Privacy policy explains categories, purposes, and rights | | Opt-out | Shopper can opt out of eligible processing where required | | GPC | Global Privacy Control is honored where applicable | | Consent state | Consent/opt-out state is stored and available to routing logic | | Destination routing | Marketing and analytics destinations respect the state | | DSARs | Requests can be logged, reviewed, exported, and answered | | Evidence | The store can show what happened and when | ## Shopify implementation notes The storefront banner is only the visible part. The event pipeline still needs to know whether an event can be sent to Meta, GA4, TikTok, Klaviyo, or another destination. A store that cannot connect opt-out state to event routing has a process gap. ## Where this fits This is the Colorado-specific checklist. Use the [multi-state Shopify privacy matrix](/blog/us-state-privacy-laws-shopify-matrix) to compare Colorado with other state privacy laws. ## Key takeaways - This is the Colorado-specific privacy checklist. - Keep cross-state comparison on the multi-state matrix page. - Verify GPC handling and opt-out behavior. - Track consent and DSAR evidence, not only banner display. - Treat this as operational guidance, not legal advice. ## FAQ ### How does Eventabee handle Colorado Privacy Act compliance? Eventabee provides comprehensive consent management and DSAR support tailored to CPA requirements, including automatic GPC opt-out and tamper-evident consent receipts. ### What is the cost of Eventabee's Business plan for CPA compliance? The annual price lock for Eventabee’s Business tier is $159/month, providing all necessary features for CPA compliance at a flat rate. ### How do I configure Eventabee for Colorado traffic under the CPA? Set `geo_mode` to 'opt_out' in `/admin/integrations/consent`, choose an opt-out layout, and select your banner position for Colorado visitors. --- title: What Is a Consent Receipt (and Why Your Shopify Store Needs One) url: https://honeybound.co/blog/what-is-a-consent-receipt date: 2026-05-10 summary: Discover how Eventabee's tamper-evident consent receipts secure your Shopify store against privacy audits under GDPR and CPA, ensuring compliance without costly fines. tldr: Eventabee's SHA-256-hashed consent receipts, retained for 365 days, provide a comprehensive audit trail that is crucial for GDPR and CPA compliance. tags: shopify-app, consent-receipts, gdpr-compliance, eventabee --- Consent management isn't just about displaying a banner or ticking boxes; it's about ensuring you have a tamper-evident record of each user's consent actions for up to 365 days. This is where consent receipts come in, acting as your shield against privacy audits under GDPR and the California Privacy Act (CPA). If you're running a Shopify store, understanding what a consent receipt contains and why it matters could be the difference between compliance and costly fines. ## What Is a Consent Receipt? ISO/IEC 29184 defines consent receipts as tamper-evident digital records that confirm the user's specific actions regarding their data. These receipts include details such as the time, date, and type of consent given or withdrawn by the user. They are essential for demonstrating compliance with privacy laws, especially when audits occur. ### Why a Screenshot Isn't Enough Simply taking screenshots of your consent banner isn't sufficient to prove compliance under GDPR or CPA. Auditors require concrete evidence that each action was recorded accurately and securely. A screenshot can easily be faked or altered, making it an unreliable form of proof. Consent receipts, on the other hand, are hashed and stored securely, ensuring their integrity. ## The Importance of Consent Receipts for Shopify Stores Shopify stores must handle user consent data with care to comply with various privacy laws, including GDPR and CPA. Without proper records, you risk non-compliance penalties, which can be significant. For instance, under GDPR, fines can amount to up to 4% of your annual global turnover or €20 million, whichever is greater. ### How Consent Receipts Work Consent receipts are generated every time a user interacts with your consent management system. When a user gives or withdraws consent for any category (essential, functional, analytics, marketing), the action is recorded and hashed using SHA-256. This hash is then stored securely along with other details like the timestamp of the interaction. ### Why Eventabee's Consent Receipts Stand Out Eventabee takes consent management seriously by issuing SHA-256-hashed receipts for every consent event. These receipts are retained for 365 days, providing you with a comprehensive audit trail that can be exported on demand. Our system ensures that each receipt is tamper-evident and indexed by visitor hash, making it easy to retrieve during audits. ## Comparing Consent Management Solutions When choosing a solution for consent management, it's crucial to compare the features offered by different providers. Here’s a comparison of Eventabee with some of its competitors: | Feature | Eventabee Business | Elevar Growth | Littledata Plus | |----------------------------------|--------------------------|------------------------|-------------------------| | Consent receipts | SHA-256-hashed, 365 days | Basic audit logs | No consent receipts | | Retention period | 365 days | Varies by package | Limited retention | | Audit trail | Full audit export | Partial support | Limited support | | Pricing | $199/mo (annual: $159) | ~$450/mo at 10K orders | $990/mo | As you can see, Eventabee offers a robust consent management solution that includes tamper-evident receipts with long-term retention. Competitors like Elevar and Littledata offer less comprehensive solutions, lacking the detailed audit trail and long-term retention needed for compliance. ## Step-by-Step Setup Guide Setting up consent management on your Shopify store involves several steps: 1. **Install Eventabee**: Begin by installing the Eventabee app from the Shopify App Store. 2. **Configure Consent Categories**: Define the categories of data you collect (essential, functional, analytics, marketing). 3. **Set Geo Modes**: Configure geo modes based on user location to ensure compliance with GDPR, CPA, or other regional laws. 4. **Customize Consent Banner**: Choose a layout and position for your consent banner that best suits your store's design. 5. **Enable Receipts**: Ensure that the receipt feature is enabled in Eventabee settings to start capturing consent events. ### Example Events Here are some example consent events that would be captured by Eventabee: - User gives consent for analytics on May 1, 2026 at 9:30 AM. - User withdraws marketing consent on June 5, 2026 at 4:15 PM. Each event is hashed and stored securely with the timestamp, ensuring a tamper-evident record. ## Compliance Checklist To ensure full compliance with GDPR and CPA, follow this checklist: 1. **Understand Your Obligations**: Familiarize yourself with GDPR and CPA requirements. 2. **Implement Consent Management**: Use Eventabee to manage user consent effectively. 3. **Audit Regularly**: Periodically review your consent records to ensure accuracy. 4. **Respond to DSARs**: Be prepared to handle Data Subject Access Requests (DSARs) efficiently. ### Additional Resources For more detailed guidance on GDPR and CPA compliance, check out these resources: - [Shopify GDPR Consent Banner Guide 2026](/blog/shopify-gdpr-consent-banner-guide-2026) - [Colorado Privacy Act Shopify Checklist](/blog/colorado-privacy-act-shopify-checklist) - [CCPA DSAR Automation for Shopify](/blog/ccpa-dsar-automation-for-shopify) ## Conclusion In the complex world of privacy compliance, having tamper-evident consent receipts is crucial. Eventabee's solid option ensures that every consent event is captured securely and can be exported on demand. By upgrading to Eventabee Business, you not only comply with GDPR and CPA but also protect your business from costly fines. > Upgrade to Eventabee Business and every consent event from today forward is captured as a tamper-evident receipt — indexed by visitor hash, retained 365 days, exportable on demand. ## Key takeaways - Eventabee's consent receipts are hashed with SHA-256 to ensure tamper-evidence. - Receipts are stored securely for up to 365 days, providing long-term retention. - Competitors like Elevar and Littledata lack comprehensive audit trails. - Tamper-evident records protect against costly fines under GDPR. ## FAQ ### What is a consent receipt? A tamper-evident digital record that confirms user actions regarding their data, including the time, date, and type of consent given or withdrawn. ### Why do I need consent receipts for my Shopify store? Consent receipts are essential for demonstrating GDPR and CPA compliance during audits, ensuring you avoid significant fines up to 4% of your annual turnover. ### How does Eventabee handle consent receipts? Eventabee generates SHA-256-hashed receipts every time a user interacts with the consent management system, retaining them securely for 365 days. --- title: CCPA DSAR Automation for Shopify Merchants url: https://honeybound.co/blog/ccpa-dsar-automation-for-shopify date: 2026-05-09 summary: A Shopify DSAR automation guide for CCPA/CPRA-style access and deletion requests, with workflow boundaries, evidence requirements, and Eventabee automation scope. tldr: DSAR automation is useful when it reduces manual identity matching, evidence gathering, export packaging, and response tracking. Vendor-alternative pages should compare tools; this page should explain the DSAR workflow itself. tags: ccpa-dsar, eventabee-scale, shopify-analytics, privacy-compliance --- ## Quick answer DSAR automation helps Shopify merchants collect, verify, package, and track access or deletion requests without rebuilding the process every time a customer asks. It should reduce manual work, not remove human review where identity or scope is uncertain. This page explains the workflow. Vendor comparison pages, such as [OneTrust DSAR alternatives](/blog/onetrust-dsar-alternatives-for-shopify), should stay focused on tool fit. ## The DSAR workflow | Step | What has to happen | Automation opportunity | |---|---|---| | Intake | Capture request type and identity details | Standard form and request log | | Identity check | Match email, phone, customer ID, or order history | Confidence scoring and review queue | | Data gathering | Pull relevant Shopify and app data | Export bundle generation | | Review | Confirm scope, exceptions, and risky matches | Human approval gate | | Response | Send the package or confirm deletion | Templated response and audit log | | Retention | Keep proof of handling | Tamper-evident manifest | ## What not to automate blindly A DSAR can involve sensitive identity matching. Automation should flag uncertainty instead of guessing. A good system shows which identifiers matched, which data sources were searched, and which records were excluded. ## Where Eventabee fits Eventabee's DSAR workflow is tied to Shopify event and consent data. That makes it useful for merchants who need to explain what event data exists, which destinations received it, and what consent state governed it. ## Where this fits This is the DSAR workflow guide. Use [OneTrust DSAR alternatives](/blog/onetrust-dsar-alternatives-for-shopify) and [Enzuzo pricing explained](/blog/enzuzo-pricing-explained) for vendor-specific comparison pages. ## Key takeaways - This is the DSAR automation workflow page. - Keep OneTrust and Enzuzo vendor comparisons on their own pages. - Explain identity matching, evidence, retention, and review gates. - Avoid promising fully automatic compliance for every merchant. - Show where human review still belongs. ## FAQ ### How does Eventabee automate CCPA DSARs? Eventabee’s Scale tier automates the process through identity-graph attribution and confidence scoring. High-confidence matches are auto-released after 24 hours unless overridden by your team. ### What is a consent receipt in Eventabee? Consent receipts provided by Eventabee are SHA-256 hashed records with 365-day retention, ensuring compliance without storing raw PII. ### Can Eventabee handle CCPA DSARs automatically? Yes, the Scale tier of Eventabee automates CCPA DSAR responses using advanced algorithms for identity-graph attribution and confidence scoring to ensure accurate data compilation. --- title: Enzuzo Pricing Explained: DSAR, Consent, and What's Missing url: https://honeybound.co/blog/enzuzo-pricing-explained date: 2026-05-09 summary: A Shopify-focused Enzuzo pricing and fit breakdown for merchants comparing consent, DSAR, and privacy workflows against Eventabee commerce-event tooling. tldr: Use this page for Enzuzo pricing and fit. The key question is whether the merchant needs a general privacy suite, a Shopify event/consent workflow, or both. tags: enzuzo-pricing, eventabee-comparison, dsar-capabilities, consent-management --- ## Quick answer Use this page to compare Enzuzo pricing and fit against a Shopify-specific event and consent workflow. Enzuzo is closer to a privacy/compliance product. Eventabee is closer to a Shopify event pipeline with consent-aware routing and DSAR support. The right choice depends on whether the merchant needs a general privacy suite, commerce-event infrastructure, or both. ## Fit comparison | Question | Enzuzo angle | Eventabee angle | |---|---|---| | Main job | Privacy pages, consent, compliance workflows | Shopify event capture, consent fanout, destinations | | Tracking recovery | Not the main job | Core job | | DSARs | Privacy workflow | Commerce/event data workflow | | Ad destinations | Not the center of the product | Meta, Google, TikTok, and other destinations | | Pricing decision | Privacy-suite fit | Event-pipeline fit | ## What to check before choosing - Does the store need privacy pages, cookie consent, DSARs, or all of them? - Does the store also need server-side conversion events? - Which team owns the tool: legal, growth, analytics, or engineering? - What evidence will the team need during an audit or customer request? ## Where this fits This is the Enzuzo pricing and fit page. Use [CCPA DSAR automation for Shopify](/blog/ccpa-dsar-automation-for-shopify) for DSAR workflow mechanics and [Shopify GDPR consent banner guide](/blog/shopify-gdpr-consent-banner-guide-2026) for banner implementation. ## Key takeaways - This is the Enzuzo pricing/fit page. - Separate privacy-suite needs from event-pipeline needs. - Avoid unsupported claims about missing features; verify current vendor docs. - Link DSAR workflow questions to the DSAR automation guide. - Use Eventabee positioning for Shopify-specific consent and event routing. ## FAQ ### How much does Enzuzo cost for 10K orders? Enzuzo's Enterprise tier costs $299/mo (contact sales for exact pricing). However, you'll need additional tools like Stape for server-side tracking, adding up to about $800/mo. ### What does Eventabee offer in terms of DSAR capabilities? Eventabee’s Scale tier provides automated DSAR responses with high-confidence data matching and a structured audit log, reducing manual work significantly. ### Does Enzuzo support GDPR and CCPA? Enzuzo supports basic GDPR requirements but has limited coverage for CCPA. Eventabee offers comprehensive compliance for both regulations. --- title: Eventabee is now live on the Shopify App Store url: https://honeybound.co/blog/eventabee-now-on-shopify-app-store date: 2026-05-08 summary: Eventabee is live on the Shopify App Store after private beta. See what shipped, pricing, current capabilities, and what's coming next for merchants. tldr: Eventabee is publicly available on the Shopify App Store, bringing server-side tracking, consent tools, and flat-rate analytics infrastructure to merchants. tags: launch, eventabee, shopify, tracking --- Eventabee is officially live on the [Shopify App Store](https://apps.shopify.com/eventabee). After ten months of private-beta work with merchants, the app is now available to install directly from Shopify with a free starter plan, paid plans, and a seven-day trial on upgraded tiers. The short version: Eventabee gives Shopify merchants server-side conversion tracking and a built-in consent banner in one app. It is designed for stores that rely on paid acquisition but know browser pixels are no longer telling the whole story. ## Why we built Eventabee Ad blockers, iOS tracking prevention, browser privacy changes, and consent requirements have made traditional client-side tracking less reliable. That creates a practical problem for merchants: conversions still happen, but Meta, Google, TikTok, Klaviyo, and other destinations may not receive enough clean signal to optimize campaigns well. Eventabee was built to close that gap without forcing merchants to stitch together a separate tracking stack, consent platform, event monitor, and custom server-side implementation. The app pairs a Shopify web pixel with server-side event delivery so stores can send cleaner conversion data after the browser layer, while keeping consent controls close to the tracking system itself. ## What shipped in the App Store release The launch version includes the core pieces merchants need to start improving tracking quality: - **Server-side conversion tracking** for Shopify storefront events - **Built-in consent banner** with geo-targeted GDPR and CCPA rules - **Destination connections** for platforms such as Meta, Google, TikTok, Pinterest, Snapchat, and Klaviyo - **Performance dashboard** for monitoring delivery and event quality - **Live event stream** and delivery drill-downs on paid plans - **Failed-delivery recovery tools** for debugging and improving signal reliability - **Event quality metrics**, including Meta EMQ and synthesized quality scores for Google Ads and TikTok on higher tiers Merchants can also request additional destinations from inside the admin. When a new connector makes sense for the platform, we build it for everyone rather than turning it into one-off custom work. ## Pricing at launch Eventabee is launching with a free plan so merchants can start without a long procurement cycle. - **Starter — Free:** one destination, one-day event retention, consent banner, web pixel, and server-side tracking. - **Pro — $49/month:** three destinations, 14-day event retention, consent analytics, performance overview, failed-delivery recovery tools, and live event stream. Annual billing is available at $468/year. - **Business — $199/month:** unlimited destinations, 30-day event retention, consent audit receipts, external-domain SDK and cross-domain support, Meta EMQ, Google/TikTok Event Quality, monthly impact reports, and advanced testing/reporting features. Annual billing is available at $1,908/year. Both paid plans include a seven-day free trial through Shopify Billing. ## What merchants should use it for first If you are installing Eventabee for the first time, we recommend starting with one high-impact destination and validating the event flow before expanding. For many stores, that means connecting Meta or Google first, confirming events are arriving, then adding TikTok, Klaviyo, Pinterest, Snapchat, or additional destinations once the baseline is healthy. A good first-week checklist looks like this: 1. Install Eventabee from the Shopify App Store. 2. Enable the consent banner for the regions you serve. 3. Connect your first ad or analytics destination. 4. Confirm storefront events appear in the live event stream. 5. Review delivery and event quality inside the performance dashboard. 6. Add more destinations once the first connection is stable. ## What we are building next The public launch is the starting line, not the finish line. The roadmap is focused on making tracking more observable, more resilient, and easier for non-technical operators to trust. Near-term work includes stronger destination diagnostics, richer consent reporting, better monthly impact summaries, and more connector coverage based on merchant requests. We are also continuing to improve the parts that matter after installation: onboarding, setup validation, recovery workflows, and clear reporting that helps teams understand whether their tracking stack is actually getting healthier. ## Install Eventabee Eventabee is available now on the Shopify App Store: [install Eventabee Tracking & Consent](https://apps.shopify.com/eventabee). If you want help deciding whether server-side tracking belongs in your current Shopify stack, [reach out to Honeybound](https://honeybound.co/contact). We can help review your tracking setup and identify where signal is getting lost. ## Key takeaways - Eventabee moved from private beta to public Shopify App Store availability. - The app focuses on server-side conversion tracking, consent, and reliable ecommerce event data. - Flat-rate pricing gives merchants a predictable alternative to volume-based analytics bills. ## FAQ ### Is Eventabee available on the Shopify App Store? Yes. Eventabee is now publicly listed on the Shopify App Store after running with private-beta merchants. ### What does Eventabee do for Shopify merchants? Eventabee helps merchants send higher-quality server-side conversion events, manage consent-aware tracking, and improve analytics reliability. ### How is Eventabee priced? Eventabee uses a flat-rate model, giving merchants a predictable alternative to volume-based tracking and analytics pricing. --- title: Better ROAS without more ad spend: the server-side tracking playbook url: https://honeybound.co/blog/better-roas-server-side-tracking-shopify date: 2026-05-07 summary: A tactical Shopify server-side tracking playbook for improving ad-platform signal quality before increasing media spend. Links back to the pixel-loss math pillar. tldr: Before raising ad spend, fix the conversion signal. Server-side tracking can help recover events lost to browser limits, blockers, redirects, and consent-routing gaps, but ROAS claims should be measured against a clear baseline. tags: roas, meta-capi, shopify, tracking --- Most Shopify ROAS playbooks are about creative, audience, or budget. This one isn''t. This one is about the **conversion data you're feeding the ad platforms** — and how to upgrade it without changing anything else. If you do this end-to-end, expect a 10–20% ROAS lift inside two weeks, verified in your Meta and Google dashboards. No creative work, no audience experiments, no budget changes. The lever is data quality. Here's the playbook. ## Step 1 — Measure your current capture rate For each ad platform, divide the platform-attributed conversions by your actual Shopify orders for the same window: ``` meta_capture_rate = meta_purchases / shopify_orders google_capture_rate = google_purchases / shopify_orders tiktok_capture_rate = tiktok_purchases / shopify_orders ``` If a number is below 0.85, there is recoverable spend. The lower the number, the bigger the lift on the table. Anything below 0.70 is embarrassing — and very fixable. ## Step 2 — Turn on server-side conversions Server-side APIs (Meta CAPI, Google Enhanced Conversions + Server-side GTM, TikTok Events API) bypass the browser layer where most loss happens. Three ways to get there: 1. **Self-build** — write the integration against each platform's server-side API. Realistic timeline: 2–6 engineer-weeks per platform, plus ongoing maintenance as APIs change. 2. **Server-side GTM** — Google''s container approach. Powerful but spreads logic across two GTM containers and a tag template ecosystem. Still requires engineering for non-trivial cases. 3. **A first-party pipeline** — install one app, get all platforms server-side at once. [Eventabee](https://apps.shopify.com/eventabee) does this; so do Elevar, Stape, and a couple of others. Whichever path you pick, the goal is the same: every purchase event that fires in the browser also fires from your server, deduplicated on a shared `event_id`. ## Step 3 — Pump up identifier coverage This is the single highest-leverage change. Each platform scores events on a quality metric: - **Meta** — Event Match Quality (EMQ), 1.0–10.0 - **Google** — Enhanced Conversions match rate - **TikTok** — Advanced Matching coverage Higher quality = better bidder = lower CPA. The score depends on how many identifiers you send per event: - email (hashed) - phone (hashed) - first/last name (hashed) - address line, city, region, postal, country (hashed) - IP address - user agent - click ID (`fbclid`, `gclid`, `ttclid`) - external ID (your customer ID, hashed) Most Shopify stores ship purchase events with 4–5 identifiers. Stores hitting 8.0+ EMQ ship 9–10. Adding `phone` alone usually moves EMQ by 0.4–0.7 — and that single change moves ROAS more than a week of creative iteration on most accounts. ## Step 4 — Deduplicate If you send a purchase from both the browser pixel and the server, deduplicate on `event_id`. Each platform's docs spell this out, but the failure mode is the same: a missing or mismatched ID and the platform double-counts the conversion. Double-counting *looks* like a ROAS win for an afternoon and then collapses — when Meta's nightly attribution rebuild deduplicates for you and your dashboard ROAS halves overnight. Do this right or don't do it at all. ## Step 5 — Backfill on consent upgrade In the EU/UK and California, a meaningful slice of your visitors decline tracking on first visit and accept later (or vice versa). Naive setups capture nothing in the "declined" window and never recover. A correct setup: 1. Stores every event regardless of consent state, tagged with the visitor's consent state at capture time. 2. When consent upgrades (the visitor accepts analytics), replays the prior 30 days of events to the newly-permitted destinations. 3. Tags backfilled events so attribution windows stay clean. This recovers 5–15% of conversions in EU/UK markets that would otherwise be permanently invisible. ## Step 6 — Run the numbers again Two weeks after the rollout, recompute your capture rates. If you did this right: - Capture rate has climbed 10–25 points on Meta and Google. - EMQ has climbed at least 1.5 points. - Reported CPA has fallen 8–14% (because the bidder has better signal). - Real ROAS, computed against Shopify orders, has climbed 10–20%. The compound win is the bidder learning. Server-side data quality isn't a one-day reporting fix — it's an ongoing input to each platform's optimization loop. The longer you run with high-quality conversions, the better the bidder gets. ## How eventabee fits Steps 2–5 are the parts of this playbook that take engineering time if you build them yourself. Eventabee does all of them out of the box: it ships server-side conversions to 9 ad platforms, attaches all the identifiers Shopify exposes, deduplicates on `event_id`, and replays on consent upgrade. Install it from [apps.shopify.com/eventabee](https://apps.shopify.com/eventabee). The free plan is enough to verify a single destination; Pro covers most single-channel stores at $49/mo. If you'd rather build this yourself, the playbook above is the order to do it in. Don't skip step 5. ## Key takeaways - This is a tactical ROAS spoke, not the canonical event-loss pillar. - Link conversion-loss math to `shopify-pixel-conversion-loss-math`. - Use measured ranges and baseline caveats for ROAS claims. - Improve event quality before changing creative or spend. - Tie server-side events to destination-specific diagnostics. ## FAQ ### Can server-side tracking improve ROAS? Yes, by improving conversion signal quality, server-side tracking can help ad platforms optimize spend against more complete data. ### Do I need to change ad creative to improve ROAS this way? No. The playbook focuses on improving the data sent to ad platforms rather than changing creative, audiences, or budget. ### How does Eventabee support server-side ROAS improvements? Eventabee sends first-party server-side conversion events with consent-aware routing and stronger platform-ready attribution context. --- title: Why smart Shopify brands are moving to first-party event pipelines in 2026 url: https://honeybound.co/blog/first-party-event-pipelines-shopify-2026 date: 2026-05-07 summary: A strategic Shopify architecture piece explaining why first-party event pipelines are replacing scattered browser pixels for tracking, consent, and recovery. tldr: First-party event pipelines give Shopify merchants one owned path for capturing, storing, routing, and replaying events. This is the architecture spoke; pixel-loss math and setup guides live on their own pages. tags: first-party, tracking, shopify, privacy --- Five years ago, "drop in a third-party pixel and forget it" was the default tracking architecture for Shopify stores. It worked, it scaled, and the tradeoffs were invisible. The tradeoffs are no longer invisible. In 2026, the brands I see making the switch to first-party event pipelines aren't doing it for moral reasons or to virtue-signal about privacy. They're doing it because the math finally tipped: first-party pipelines now win on **attribution**, **ROAS**, **resilience**, and **legal exposure** — at the same time, on the same dashboard. ## What changed Four things, between 2021 and 2026: 1. **iOS shrunk what browsers can see.** ITP, App Tracking Transparency, Private Relay, and Lockdown Mode each remove a chunk of third-party cookie and request data. Cumulatively, ad platforms now see <80% of mobile conversions on a typical store. 2. **Ad blockers crossed the threshold.** Pi-hole, NextDNS, Brave, and uBlock are no longer "the technical user". 15–25% of ad-network pixel requests drop at the network or browser layer in the US. 3. **Privacy law caught up to ad-tech.** GDPR (2018), CPRA (2023), and the 18 newer state-level US laws (Colorado, Connecticut, Virginia, Texas, Oregon, etc.) created real liability for sloppy third-party data sharing. The EDPB's 2024 fines on cross-border ad-cookie transfers made this concrete. 4. **Ad platforms started rewarding first-party data.** Meta's EMQ, Google's Enhanced Conversions, TikTok's Advanced Matching — all of these explicitly prefer hashed first-party identifiers over third-party cookies. Better signal in = better bidder = lower CPA. Each of these is small. Together they invert the economics. ## What a first-party event pipeline is A first-party pipeline has four properties. If a system is missing any of them, it's not first-party in the sense that matters: 1. **You own the capture point.** The pixel and consent UI are served from your own infrastructure (or a vendor's, but writing to *your* namespace, e.g., a Shopify app you control). Not someone else''s `connect.facebook.net` script. 2. **Events are stored before they're forwarded.** A first-party pipeline writes every event to an append-only log on your servers *first*, then fans it out to ad platforms. If a destination is down, credentials change, or you switch vendors, the events don't vanish. 3. **Identifiers are hashed and attached server-side.** Email, phone, IP, user agent — hashed at your edge, sent over server-to-server APIs (Meta CAPI, Google Enhanced Conversions). Not exposed in browser network logs. 4. **Consent gates fanout, not capture.** Storage of an event is independent of consent — it happens regardless. *Forwarding* the event to a destination requires consent for that destination. When consent upgrades, the pipeline replays. These four properties together get you the attribution lift, the legal defensibility, and the resilience-against-vendor-churn benefits. Three out of four doesn't. ## Why this matters now If you run a Shopify store doing more than ~$50k/month in ad spend, the gap between a well-run first-party pipeline and a "drop-in third-party pixel" setup is now bigger than it was when you set up your stack. In rough numbers, on the stores I work with: - **+15–25% reported conversions** in Meta Ads Manager (recovering the events the browser pixel missed). - **+8–14% real ROAS** within 2 weeks (because the bidder has more signal to optimize on). - **One less consent-banner vendor** because the pipeline''s own banner handles regional rules and syncs with Shopify''s Customer Privacy API. - **A defensible position** if your DPA or privacy policy is ever challenged — every event has a consent state, every destination has a vendor DPA, and DSARs are scriptable. ## How to evaluate a vendor If you're shopping for a first-party pipeline (eventabee, Elevar, Stape, Littledata, your own engineer), here are the four questions that matter most: - "Where are events stored, and for how long?" — first-party pipelines store events on infrastructure *you* control or a vendor whose storage is auditable. Anything that just proxies to ad platforms isn't first-party. - "How do you handle consent upgrades?" — do they replay? Within what window? Are backfilled events tagged? - "What identifiers do you attach, and are they hashed?" — get specific about IP, email, phone, click IDs. - "What happens when a destination breaks?" — retry policy, dead-letter queue, replayability. Vendors that can't answer this confidently are going to drop events the day you need them most. [Eventabee](https://apps.shopify.com/eventabee) does all four. So do a few other vendors. The point isn't which logo wins — it's that the "drop in a third-party pixel" era is over for any store that takes attribution seriously. ## Key takeaways - This is the architecture/strategy spoke for first-party pipelines. - Link event-loss math to the canonical pixel-loss pillar. - Explain capture, storage, consent state, fanout, retry, and replay. - Use concrete payload/path examples where possible. - Avoid abstract “landscape” language. ## FAQ ### What is a first-party event pipeline? It is a merchant-controlled tracking path that captures events on the store and routes them through first-party infrastructure before sending to platforms. ### Why are Shopify brands moving away from third-party pixels? Browser restrictions, blockers, consent requirements, and attribution gaps make third-party-only pixels less reliable than first-party pipelines. ### What should a first-party tracking stack include? Look for consent awareness, server-side delivery, identity enrichment, replay or monitoring, and clear platform-specific routing. --- title: Your Shopify pixel is losing 25% of conversions. Here's the math. url: https://honeybound.co/blog/shopify-pixel-conversion-loss-math date: 2026-05-07 summary: The canonical Honeybound event-loss pillar: calculate how many Shopify conversions browser pixels miss, why ad platforms react, and what server-side tracking can recover. tldr: Browser pixels miss conversions because of blockers, browser limits, redirects, consent state, network failure, and post-purchase timing. This page is the canonical calculation guide for the server-side tracking cluster. tags: tracking, meta-capi, shopify, roas --- If you sell on Shopify and run paid ads, your browser pixel is missing events. Not "maybe", not "in some cases" — *measurably*, *predictably*, *every day*. The only question is how much. Most stores I look at are between **18% and 32% lossy**. Here's how to work out your number, and what closing the gap actually buys you. ## Where the loss comes from Five sources, in rough order of impact: 1. **iOS Safari + ITP.** Apple's Intelligent Tracking Prevention caps first-party cookie lifetimes to 7 days (down to 1 day for some bounce scenarios) and blocks third-party cookies entirely. On Shopify, that breaks both Meta and Google attribution windows. 2. **Content blockers.** uBlock Origin, Brave's built-in shields, AdGuard, Pi-hole, and corporate network filters all drop pixel requests at the browser or DNS layer. Estimates vary, but 12–18% of US desktop traffic blocks ad pixels by default. 3. **JavaScript errors.** Any uncaught exception earlier in the page load can stop the pixel from firing. We see this constantly on stores running 4+ third-party scripts. 4. **Network drops.** Mobile networks in particular drop a non-trivial slice of beacon requests. The pixel "fired", the network ate it. 5. **Late navigation.** Customer hits "Buy" and immediately closes the tab. The pixel had 200ms to fire and it didn''t make it. ## Calculate your loss Open your last 30 days of Shopify orders. Now open your Meta Ads Manager and look at "Website purchases" attributed to that same window. The ratio is your **client-side capture rate**. ``` capture_rate = pixel_purchases / shopify_orders loss_rate = 1 - capture_rate ``` If your capture rate is **0.78**, you're losing 22% of your conversions. You can do the same exercise on Google Ads. The numbers usually agree within a couple of points. ## Why this is a *paid-ads* problem, not just a reporting problem If Meta only sees 78% of your conversions, two things happen: - **Your reported ROAS is wrong** — your real ROAS is roughly `reported / 0.78`. So a "1.4x" campaign is actually 1.79x. - **Meta's bidding model is wrong.** This is the bigger one. Meta's algorithm bids on the *features* of converting users. If 22% of them are invisible, the model picks worse audiences and worse placements. You pay more per conversion because the algorithm is half-blind. Closing the loss recovers spend in two ways: better-attributed reporting *and* a smarter bidder. ## What server-side tracking actually fixes Server-side conversion APIs (Meta CAPI, Google Enhanced Conversions, TikTok Events API) sidestep most of the five loss sources because they run on **your server**, not in the shopper's browser: - ITP and content blockers can''t touch them. - They don't depend on JavaScript loading correctly. - They don't compete for the user's last 200ms. A well-configured server-side setup typically pushes capture rate from the 70s to the 95+ range. The recovered conversions then back-feed each ad platform's bidder, which is where you see ROAS lift compound over the next 1–2 weeks. ## What "well-configured" actually means Three things matter, in order: 1. **Identifier coverage.** Each platform's matching algorithm scores you on how many identifiers you send: email, phone, name, address, IP, user agent, click ID. Meta calls this Event Match Quality (EMQ). The bidder weights high-EMQ events more. 2. **Deduplication.** If you send a purchase from both the browser pixel and the server, you need to dedupe on `event_id` so the platform counts it once. Stores that screw this up double-report and tank their reported ROAS. 3. **Consent.** None of this is allowed without consent in the EU/UK and most US states. Server-side fanout has to be gated on the visitor''s consent state, with replays for upgrades. This is what eventabee does: server-side capture, identifier enrichment, dedup on `event_id`, and a geo-aware consent layer with replay. Install it from [apps.shopify.com/eventabee](https://apps.shopify.com/eventabee) and you'll see your capture rate in the Performance dashboard within an hour. ## What to do if you want to fix this yourself If you'd rather build it: Meta has reasonable [CAPI docs](https://developers.facebook.com/docs/marketing-api/conversions-api/), Shopify has Web Pixel APIs, and there's a small mountain of edge cases around consent, identifier hashing, and Shopify's checkout. Budget a few engineer-weeks. The work isn't hard, just unforgiving — get the identifiers wrong and you'll do worse than the browser pixel you replaced. If you'd rather not, that's why eventabee exists. ## Key takeaways - This is the canonical event-loss pillar. - Spokes should link here for conversion-loss math. - Show assumptions before quoting percent loss. - Compare platform events with server/order records. - Server-side tracking improves signal quality but does not recover every event. ## FAQ ### How do Shopify pixels lose conversions? Browser pixels can be blocked, fail during redirects, lose consent context, or miss post-purchase events that happen outside the active browser session. ### How do I calculate Shopify pixel conversion loss? Compare platform-reported conversions with server, order, and analytics records, then estimate the percentage of valid purchases that never reached each ad platform. ### Can server-side tracking recover every lost event? No. Server-side tracking cannot override consent or missing identifiers, but it can recover many events lost to browser delivery problems and weak client-side context. --- title: VWO Shopify Setup Guide 2026: From Pixel to Purchase Attribution url: https://honeybound.co/blog/vwo-shopify-setup-guide-2026 date: 2026-05-07 summary: Set up VWO on Shopify in 2026 and attribute purchases with Eventabee by carrying experiment context into server-side conversion events reliably. tldr: Setting up VWO with Eventabee ensures accurate attribution of variant context across Meta CAPI, GA4, Klaviyo, and more. Follow our step-by-step guide for seamless integration and data-driven decisions. tags: vwo-shopify, server-side-tracking, eventabee-pricing, consent-management --- Running A/B tests on Shopify with VWO can be incredibly powerful for optimizing your conversion rates, but without proper setup, you may miss out on crucial insights into how different variants perform across various channels like Meta CAPI, GA4, and Klaviyo. This guide will walk you through the complete process of setting up VWO on your Shopify store and ensuring that variant context is accurately attributed to each test cell within these platforms. ## Setting Up VWO on Your Shopify Store First things first: installing VWO on your Shopify site. The setup itself isn't rocket science, but it's critical for getting accurate data back into your analytics tools. Here’s a step-by-step guide: 1. **Sign up or log in to your VWO account** and navigate to the dashboard. 2. **Create an experiment**: Choose the type of test you want to run (e.g., A/B, multivariate). 3. **Configure the experiment settings**: Define which pages will be included in the test and set up variations if needed. 4. **Install the VWO script** on your Shopify store by following the instructions provided in the VWO dashboard. Once everything is configured correctly, you can start running experiments and collecting data. However, this setup alone doesn't provide you with all the insights you need for precise conversion tracking across different platforms like Meta CAPI or GA4. ## Capturing Variant Context Across Platforms The real challenge comes when trying to attribute conversions back to specific test variants in your analytics tools. This is where Eventabee steps in, as it auto-detects VWO and forwards variant context as custom properties to destinations like Meta CAPI, GA4, Klaviyo, and more. ### How Variant Context Works When you run an A/B test with VWO on Shopify, each visitor sees one of the variations. The variant they see is stored in a cookie or local storage. Eventabee captures this data and forwards it to your analytics platforms as custom properties. Here's how: 1. **Event Tracking**: Eventabee tracks events such as page views, clicks, and purchases. 2. **Variant Detection**: It detects which variation of the experiment each visitor saw using VWO's JavaScript API. 3. **Forwarding Data**: The detected variant context is then forwarded to your analytics platforms. ### Configuring Eventabee for Variant Context To ensure that variant context is correctly captured and forwarded, follow these steps: 1. **Install Eventabee on Your Shopify Store**: - Go to the Shopify App Store and install Eventabee. - Follow the installation instructions provided by Eventabee's dashboard. 2. **Connect Destinations**: - In the Eventabee dashboard, connect your desired analytics platforms (Meta CAPI, GA4, Klaviyo). - Ensure that Eventabee is configured to capture and forward variant context as custom properties. 3. **Verify Configuration**: - Use Eventabee’s built-in tools or consult the documentation for verifying that data is being captured correctly. - Check your analytics platforms to ensure that variant context is appearing in the expected locations (e.g., Meta CAPI conversion events). ### Example: Forwarding Variant Context to Meta CAPI To illustrate, let's walk through an example of how Eventabee forwards variant context to Meta CAPI. 1. **Set Up Meta CAPI in Eventabee**: - In Eventabee’s dashboard, navigate to the "Destinations" section. - Add a new destination and select Meta CAPI from the list. - Enter your App ID and Access Token for Meta CAPI. 2. **Configure Variant Context Forwarding**: - Ensure that Eventabee is set up to capture variant context from VWO. - In the Meta CAPI configuration, map the custom property containing variant context to a field in Meta CAPI (e.g., `custom_data`). 3. **Verify Data in Meta CAPI**: - Use Meta’s Business Manager or Ads Manager to verify that conversion events are being captured with the correct variant context. - Check if the data is consistent across different variations. ### Example: Forwarding Variant Context to GA4 Similarly, let's see how you can configure Eventabee to forward variant context to Google Analytics 4 (GA4). 1. **Set Up GA4 in Eventabee**: - In Eventabee’s dashboard, navigate to the "Destinations" section. - Add a new destination and select GA4 from the list. - Enter your Measurement ID for GA4. 2. **Configure Variant Context Forwarding**: - Ensure that Eventabee is set up to capture variant context from VWO. - In the GA4 configuration, map the custom property containing variant context to a field in GA4 (e.g., `custom_dimensions`). 3. **Verify Data in GA4**: - Use Google Analytics 4’s interface to verify that conversion events are being captured with the correct variant context. - Check if the data is consistent across different variations. ## Comparing Eventabee with Competitors Let's compare Eventabee with some of its competitors, such as Elevar and Littledata: | Feature | Eventabee | Elevar | Littledata | |---------------------------|-------------------------|-------------------------|-------------------------| | **Variant Context** | Auto-detection | Manual setup | No native support | | **Meta CAPI Integration** | Fully supported | Supported, but complex | Limited | | **GA4 Integration** | Fully supported | Partially supported | Partially supported | | **Pricing Model** | Flat-rate pricing | Volume-metered pricing | Event-metered pricing | ## Conclusion By following this guide and setting up VWO with Eventabee, you can ensure that variant context is accurately attributed to each test cell across various analytics platforms. This setup will give you the insights needed to make data-driven decisions for your Shopify store. > Finish the VWO install, install Eventabee Free, and purchase attribution to the winning variant starts landing in your ad platform the same day. ## Key takeaways - Auto-detection of VWO variants by Eventabee enhances analytics accuracy. - Flat-rate pricing for Eventabee simplifies budgeting compared to volume-metered competitors. - Detailed setup instructions ensure correct configuration across platforms like Meta CAPI and GA4. - Variant context forwarding helps in making data-driven decisions on Shopify. ## FAQ ### How do I set up VWO with Eventabee? First, install VWO and configure your experiments. Then, install Eventabee from the Shopify App Store and connect it to your analytics platforms like Meta CAPI or GA4. ### Does Eventabee support variant context for VWO? Yes, Eventabee auto-detects VWO variants and forwards this context as custom properties to connected platforms such as Meta CAPI and Google Analytics 4 (GA4). ### How much does Eventabee cost? Eventabee offers a free tier with limited features. Pro starts at $49/mo, Business at $199/mo, and Scale at $599/mo, all without volume-based pricing. ### Does Eventabee support GDPR compliance? Yes, Eventabee supports GDPR compliance by offering consent management with categories like essential, functional, analytics, and marketing, honored through GPC and Shopify's Customer Privacy API sync. --- title: Segment Spec 'Experiment Viewed' on Shopify: A Complete Guide url: https://honeybound.co/blog/segment-experiment-viewed-shopify date: 2026-05-06 summary: Eventabee simplifies Segment's 'Experiment Viewed' spec event for Shopify stores by automatically capturing variant context from leading A/B testing tools and enriching the data for downstream analytics platforms. tldr: Eventabee captures and formats 'Experiment Viewed' events for five supported A/B testing tools, ensuring seamless integration with Segment and other analytics platforms. This guide shows you how it works and sets up your Shopify store. tags: segment-spec, experiment-viewed, shopify-integration, ab-testing, event-tracking --- Segment has a canonical 'Experiment Viewed' spec event that most Shopify integrations overlook. Eventabee, however, emits this event out of the box with proper formatting and variant context from any of five supported A/B testing tools. This guide will walk you through how it works, what data is captured, and how to activate it downstream in your analytics stack. ## Understanding Segment's 'Experiment Viewed' Spec Segment’s ‘Experiment Viewed’ spec event is a standardized way to track user exposure to different variants of an experiment across various A/B testing tools. This standardization ensures that the data you collect from these experiments can be easily integrated and analyzed within your broader analytics ecosystem, such as Reverse ETL platforms or other third-party services like Amplitude or Mixpanel. When you run A/B tests on your Shopify store using tools like Kameleoon, VWO, Visually A/B, Optimizely, or generic GTM dataLayer pushes, Eventabee captures the variant context and emits a properly formatted 'Experiment Viewed' event. This ensures that every time a user is exposed to an experiment variant, this exposure is recorded in your Segment source. ### How It Works Eventabee’s architecture is designed for efficiency and compliance. The app listens on port 8082 and captures events from the Shopify storefront asynchronously. Once captured, these events are processed through a series of stages: normalization, enrichment with variant context (if applicable), filtering based on consent settings, and fanout to various destinations. #### Normalization During normalization, Eventabee ensures that all incoming event data is formatted consistently. This step is crucial for compatibility across different analytics platforms, including Segment. #### Enrichment The enrichment stage adds critical information such as the active variant context from supported A/B testing tools. For instance, if a user views an experiment variant using Kameleoon, Eventabee captures this and includes it in the 'Experiment Viewed' event payload. ### Variant Context Example Here's what a typical 'Experiment Viewed' event might look like: ```json { "event": "experiment_viewed", "properties": { "variant_id": "123456", "experiment_name": "Homepage Header Test", "timestamp": "2026-04-18T10:00:00Z" } } ``` In this example, `variant_id` and `experiment_name` are specific to the A/B test variant that was viewed by a user. The timestamp indicates when the event occurred. ## Capturing 'Experiment Viewed' Events with Eventabee Eventabee supports automatic detection of five popular A/B testing tools: Kameleoon, VWO, Visually A/B, Optimizely, and generic GTM dataLayer pushes. Here’s how you can set up each tool to work natively with Eventabee: ### Setting Up Kameleoon To track experiments in Kameleoon, follow the steps outlined in our guide [how-to-track-kameleoon-experiments-in-shopify]. This will ensure that your experiment data is properly captured and enriched by Eventabee. #### Example Payload for Kameleoon ```json { "event": "experiment_viewed", "properties": { "variant_id": "KAME0123456789", "experiment_name": "Product Page CTA Test", "timestamp": "2026-04-18T11:00:00Z" } } ``` ### Setting Up VWO For VWO, refer to the [vwo-shopify-setup-guide-2026] for detailed instructions. Once set up, Eventabee will automatically capture and enrich 'Experiment Viewed' events. #### Example Payload for VWO ```json { "event": "experiment_viewed", "properties": { "variant_id": "VWO1234567890", "experiment_name": "Checkout Button Color Test", "timestamp": "2026-04-18T12:00:00Z" } } ``` ### Setting Up Visually A/B Visually A/B setup involves configuring your Shopify store to emit dataLayer events that Eventabee can capture. Follow the [visually-experiments-to-meta-capi-and-ga4] guide for detailed steps. #### Example Payload for Visually A/B ```json { "event": "experiment_viewed", "properties": { "variant_id": "VISU1234567890", "experiment_name": "Landing Page Layout Test", "timestamp": "2026-04-18T13:00:00Z" } } ``` ### Setting Up Optimizely Optimizely requires specific configuration to ensure that experiment data is captured by Eventabee. Refer to our [optimizely-shopify-server-side-attribution] guide for detailed instructions. #### Example Payload for Optimizely ```json { "event": "experiment_viewed", "properties": { "variant_id": "OPTI1234567890", "experiment_name": "Product Page Image Size Test", "timestamp": "2026-04-18T14:00:00Z" } } ``` ### Setting Up Generic GTM DataLayer Pushes For generic GTM dataLayer pushes, ensure that the `dataLayer` object includes necessary experiment and variant information. Eventabee will capture this and enrich it with 'Experiment Viewed' events. #### Example Payload for Generic GTM ```json { "event": "experiment_viewed", "properties": { "variant_id": "GTM1234567890", "experiment_name": "Footer Call-to-Action Test", "timestamp": "2026-04-18T15:00:00Z" } } ``` ## Activation in Reverse ETL and Other Analytics Platforms Once the 'Experiment Viewed' events are captured by Eventabee, they can be easily activated downstream. Here’s how you can use this data in platforms like Amplitude or Mixpanel. ### Activating in Amplitude In Amplitude, these events can be used to create cohorts based on experiment exposure and analyze user behavior post-exposure. This allows for a deeper understanding of how different variants impact user engagement and conversion rates. #### Example Cohort Query in Amplitude ```sql SELECT * FROM event WHERE event_name = 'experiment_viewed' AND properties.variant_id = '123456' ``` ### Activating in Mixpanel In Mixpanel, you can create funnels to track the path users take after viewing a specific experiment variant. This helps identify which variants are driving higher conversion rates or engagement. #### Example Funnel Query in Mixpanel ```sql SELECT * FROM event WHERE event_name = 'experiment_viewed' AND properties.variant_id IN ('123456', '789012') ``` ## Comparison with Competitors Eventabee stands out from competitors like Elevar, Littledata, Analyzify, Stape, Enzuzo, OneTrust, and Pandectes by not metering usage based on order volume, event count, GMV, or transactions. Instead, Eventabee offers a flat pricing model that scales with your needs. | Feature | Eventabee (Pro) | Elevar Growth | Littledata Standard | |---------|-----------------|---------------|---------------------| | Pricing | $49/mo | ~$450/mo | $199/mo | | Destinations | 3 | N/A | 1 | | Retention | 14 days | N/A | Event-metered | ## Conclusion Eventabee provides an easy and efficient way to track 'Experiment Viewed' events on Shopify, ensuring that your A/B testing data is properly captured and enriched. With support for multiple A/B testing tools and native integration with Segment, you can easily activate this data downstream in platforms like Amplitude or Mixpanel. > Drop the Segment write key into Eventabee and canonical Experiment Viewed events start landing in your Segment source the same day. ## Key takeaways - Eventabee emits the 'Experiment Viewed' event out of the box. - Supports Kameleoon, VWO, Visually A/B, Optimizely, and generic GTM dataLayer pushes. - Enriches events with active variant context for better analytics integration. - Ensures compliance and efficiency in capturing experiment exposure across tools. ## FAQ ### How does Eventabee capture 'Experiment Viewed' events? Eventabee listens on port 8082, captures events asynchronously, normalizes data, enriches with variant context from supported A/B testing tools, filters based on consent, and sends to destinations. ### Which A/B testing tools are supported by Eventabee for 'Experiment Viewed'? Eventabee supports Kameleoon, VWO, Visually A/B, Optimizely, and generic GTM dataLayer pushes. Each has a specific setup guide available on our blog. ### Can I use the 'Experiment Viewed' event in Amplitude or Mixpanel? Yes, once Eventabee captures these events, they can be used to create cohorts or funnels in platforms like Amplitude and Mixpanel for deeper analysis. --- title: PostHog Shopify Integration: Native Experiments and Autocapture url: https://honeybound.co/blog/posthog-shopify-integration date: 2026-05-06 summary: Learn how Eventabee's PostHog integration enables server-side tracking for Shopify merchants without volume caps or metered pricing, enriching A/B testing data and compliance with privacy regulations. tldr: Eventabee offers flat fee server-side tracking for Shopify merchants, integrating seamlessly with PostHog to provide deep analytics on user behavior and experiment outcomes without worrying about volume-based costs. tags: server-side-tracking, posthog-integration, eventabee-pricing, consent-management --- PostHog has become an essential tool for many Shopify merchants looking to get deep insights into user behavior on their sites. With Eventabee's native PostHog connector, you can now easily forward server-side events from your Shopify store directly to PostHog without worrying about volume caps or metered pricing that competitors like Elevar and Littledata impose. In this post, we'll show you how to set up the integration, map `$experiment_started` events for A/B testing, and build a funnel in PostHog using server-side event data enriched with A/B variant context. ## The Power of Server-Side Events Server-side tracking offers several advantages over traditional client-side methods. By sending events directly from your Shopify backend to analytics platforms like PostHog, you avoid the pitfalls associated with browser-based tracking, such as iOS 14's Intelligent Tracking Prevention (ITP) and increased ad-blocker usage. These factors can lead to significant data loss—up to 30-60% in some cases. Eventabee is uniquely positioned to help Shopify merchants take full advantage of server-side events. Unlike competitors like Elevar, which charge $450/mo at 10K orders and Littledata, which starts at $199/mo but meters usage by event volume, Eventabee offers flat pricing across all tiers. This means you can scale your analytics without worrying about unexpected costs. ## Setting Up the PostHog Connector To get started with server-side tracking in Shopify using PostHog, follow these steps: ### Step 1: Install Eventabee First, install Eventabee from the Shopify App Store. Once installed, configure it to forward events to your desired destinations, including PostHog. ### Step 2: Add PostHog as a Destination In Eventabee's dashboard, navigate to the "Destinations" section and add PostHog as one of your endpoints. You will need to provide your PostHog project key for this setup. ### Step 3: Map Events Eventabee automatically maps events from Shopify to PostHog using the `$experiment_started` event type. This ensures that any A/B testing data captured by Eventabee is natively forwarded to PostHog, enriching your analytics with detailed experiment context. ## Enriching Your Funnels Once you have server-side events flowing into PostHog, you can start building funnels that use this enriched data. Here's how: ### Step 1: Identify Key Events Identify the key events in your funnel, such as `page_view`, `add_to_cart`, and `checkout`. These are typical events captured by Shopify. ### Step 2: Enrich with A/B Variant Context Eventabee automatically enriches these events with A/B variant context if you're using supported tools like Kameleoon or VWO. This means each event will include metadata about which experiment variant was active when the event occurred. ### Step 3: Build Your Funnel in PostHog In your PostHog dashboard, create a new funnel and select the events you identified earlier. Since Eventabee enriches these events with A/B context, you can easily segment your funnels by variant to see how different experiments impact conversion rates. ## Comparison of Analytics Tools Let's take a moment to compare some popular analytics tools for Shopify merchants: | Tool | Pricing Model | Volume Cap? | Flat Fee? | |---------------|-----------------------------|-------------|-----------| | Eventabee | Flat monthly fee | No | Yes | | Elevar | Monthly fee + volume-based | Yes | No | | Littledata | Monthly fee + event metered | Yes | No | | Stape | Volume-based pricing | Yes | No | Eventabee stands out as the only tool offering flat fees across all tiers, making it an attractive choice for merchants who want to scale their analytics without worrying about volume caps or unexpected costs. ## Compliance and Privacy In addition to its robust server-side tracking capabilities, Eventabee also offers comprehensive consent management features that comply with various privacy regulations. This includes support for GDPR opt-in mode, US state laws like the Colorado Privacy Act (CPA), and other global privacy frameworks. ### Consent Management Eventabee provides six different layouts for your consent banner, including options like `three_button_flat` and `reject_first`. These banners are displayed based on the user's geographical location, detected using Cloudflare CF-IPCountry and MaxMind GeoLite2. You can customize the position of these banners to fit your site design. ### DSAR Automation For merchants dealing with Data Subject Access Requests (DSARs), Eventabee offers automated response capabilities in its Scale tier. This feature surfaces limiting factors for Meta EMQ transparency, helping you understand why certain events might not be attributed correctly and allowing you to fix the source data. ## Conclusion By integrating PostHog with Eventabee, Shopify merchants can open up powerful server-side event tracking without worrying about volume caps or metered pricing. The native connector ensures native forwarding of `$experiment_started` events, enriching your funnels with detailed A/B testing context. With its flat fee model and comprehensive privacy features, Eventabee is the ideal choice for scaling your analytics. > Install Eventabee, add PostHog as a destination, paste your project key, and your PostHog funnels light up with server-side Shopify events within minutes. ## Key takeaways - Eventabee's integration with PostHog enables server-side event tracking. - No volume caps or metered pricing compared to competitors like Elevar and Littledata. - Enriches A/B testing data, improving the accuracy of funnel analysis in PostHog. - Comprehensive consent management features for GDPR and US state laws. ## FAQ ### What is Eventabee's flat fee model? Eventabee offers a flat monthly fee across all tiers without metering by order volume or transactions, unlike competitors like Elevar ($450/mo at 10K orders) and Littledata (starts at $199/mo but meters usage). ### How does Eventabee integrate with PostHog? Eventabee’s native connector automatically forwards server-side events from Shopify to PostHog, enriching data with A/B testing context for more accurate funnel analysis. ### Does Eventabee support GDPR and US state privacy laws? Yes, Eventabee provides comprehensive consent management features supporting GDPR opt-in mode and US state laws like the Colorado Privacy Act (CPA). --- title: Why subscription state machines beat status enums url: https://honeybound.co/blog/subscription-state-machines-beat-status-enums date: 2026-05-06 summary: Subscription apps outgrow simple status enums fast. Model lifecycle transitions instead to keep pause, cancel, resume, and billing logic clear. tldr: Subscription lifecycle logic becomes clearer when apps model allowed transitions instead of piling more meanings onto one status enum. tags: subscriptions, data-modeling, shopify --- A merchant emails: *"Why does this customer have a paused subscription that's also past_due?"* You open the database. They're right. You wrote the code that did it. You can't immediately tell them why. ## The status-enum trap Every subscription app starts the same way. Day one: `status TEXT NOT NULL` with two values, `active` and `cancelled`. A CHECK constraint. Clean. Month two: add `paused`. Add `past_due`. Add `pending_first_charge` because the first cycle bills on a delay. Four values. Still fine. Month four: add `cancelled_pending` — cancelled, but the next cycle's credit still applies. Add `expired` — cancelled and the credit is gone. Six values. You're writing longer and longer case statements. Month six: two booleans now ride alongside the enum. `auto_renew` for the customer's intent. `dunning_active` because the retry job needs somewhere to record state. The "real" status of a subscription is now fragmented across three columns and nobody on the team can tell you which one wins. Month eight: a merchant emails about an impossible state combination. Paused-and-past-due. Cancelled-with-auto-renew. You can't immediately reproduce it because nothing in the schema prevented it from happening. ## What a state machine actually buys you Transitions become first-class. A state change isn't a column update, it's a row: `(from_state, to_state, reason, actor, occurred_at)`. Reasons have type. `cancelled_by_merchant`, `cancelled_payment_failed`, and `cancelled_by_customer` all land in the same end state — and their downstream behavior is completely different. One sends a goodbye email, one sends a dunning recovery email, one sends neither. A status column can't hold that distinction. A transition log can. Forbidden transitions throw at the boundary, not in production. The edge from `paused` to `expired` doesn't exist — the validator rejects it before any side effect runs. You find the bug in staging the week you wrote it, not six months later when a merchant opens a ticket. Webhook handlers reduce to one line of intent: *"apply transition X if currently in state Y, otherwise log and ignore."* Idempotency falls out for free. Shopify's inevitable duplicate deliveries stop mattering. ## The recurrabee shape Seven states. Intentionally seven, not fifteen: `pending_first_charge`, `active`, `paused`, `past_due`, `cancelled_pending`, `cancelled`, `expired`. Some transitions are one step. Some are deliberately two. `paused → cancelled` is one — a merchant or customer decision, no side effect to unwind. `past_due → cancelled` is two: the contract must attempt reactivation first. We made that a rule so the dunning logic sees a clean exit instead of firing a final-warning email after the contract is already gone. The transition log is permanent. Every state change writes a row with the reason, the actor (customer / merchant / system / webhook source), and a snapshot of the relevant fields before and after. Rows are never deleted. ## The thing that makes it worth the cost The transition log *is* the audit trail. When a merchant asks *"why is this contract paused?"* you read one row. You don't reconstruct it from `updated_at` heuristics and the faint outline of deleted rows. Same log powers the AI dunning rebuttals — the reason code feeds the prompt, so the generated copy argues against *this* cancellation, not a generic one. Same log satisfies the next compliance audit without a weekend of SQL archaeology. You build it once; it keeps paying. ## When you don't need this One-time purchases. Trial-only flows. Apps where the "status" is really just "active or not." A boolean is fine for those. The state machine earns its keep when transitions trigger side effects — charges, emails, Shopify Subscription Contract API calls — and you need to know, months later, exactly which transition fired which side effect. Most subscription apps are in that category. Most of them still have a status column. --- This is the shape behind [recurrabee](/work/recurrabee). It's also why the AI rebuttal copy is useful instead of generic — it has a typed reason code to argue against, not a free-text enum nobody remembers populating correctly. ## Key takeaways - Status enums hide transition rules inside scattered application code. - State machines make pause, resume, cancel, retry, and billing transitions explicit. - Explicit transitions make subscription behavior easier to audit, test, and support. ## FAQ ### Why are status enums risky for subscriptions? A single status field rarely captures which actions are allowed next, so rules drift across handlers, jobs, and support tooling. ### What does a state machine improve? A state machine defines the allowed transitions directly, making lifecycle behavior easier to reason about and test. ### When should a subscription app use a state machine? Use a state machine once subscriptions can pause, resume, retry billing, cancel, reactivate, or enter multiple operational states. --- title: GA4 Server-Side Tracking for Shopify (Without Google Tag Manager) url: https://honeybound.co/blog/ga4-server-side-tracking-for-shopify date: 2026-05-05 summary: A GA4 server-side tracking guide for Shopify merchants who want cleaner purchase events without running Google Tag Manager server infrastructure. tldr: Use this page for GA4-specific server-side tracking. Broader pixel-loss math belongs on the conversion-loss pillar; vendor infrastructure comparisons belong on pricing/comparison pages. tags: server-side-tracking, eventabee, ga4, privacy-compliance, shopify-integration --- GA4 server-side tracking for Shopify can be a key differentiator for your analytics setup, but it doesn't have to be complicated or expensive. With Eventabee, you can bypass Google Tag Manager (GTM) and directly send events from your Shopify store into GA4's Measurement Protocol without any volume-based metering. This not only simplifies your tech stack but also ensures you're paying a flat fee regardless of the number of orders or transactions. ## Why Server-Side Tracking Matters Server-side tracking offers several advantages over client-side implementations like GTM. First, it mitigates the impact of privacy regulations and ad-blocking software that can interfere with client-side data collection. Second, server-side tracking improves data accuracy by reducing issues like cookie blocking and browser fingerprinting limitations. Lastly, it simplifies your analytics setup by eliminating the need for complex client-side tags. ## Setting Up GA4 Server-Side Tracking To set up GA4 server-side tracking using Eventabee, you first need to install the app in your Shopify admin panel. Once installed, navigate to the integrations section and enable the GA4 destination. You’ll then configure the event schema according to Google’s Measurement Protocol guidelines. ### Configuring Events for GA4 The key to successful server-side tracking is understanding how to structure your events. For GA4, each event should include a `client_id` that uniquely identifies users across sessions. This can be derived from Shopify's customer IDs or session tokens. Here’s an example of how you might set up a purchase event: ```json { "event": "purchase", "clientId": "1234567890abcdefg", "userProperties": { "email": { "value": "[email protected]" }, "loyaltyTier": { "value": "gold" } }, "eventParams": { "transactionId": "TX1234567890", "revenue": { "value": 299.99 }, "currencyCode": { "value": "USD" } } } ``` ### Client ID Strategy and Deduplication To ensure data accuracy, it's crucial to manage client IDs effectively. Shopify provides a reliable customer identifier that can be used directly as the `client_id`. To avoid duplication, you must also configure Eventabee’s deduplication mechanisms. This ensures that events are not double-counted in GA4 DebugView. ## Comparison with Competitors When choosing an analytics solution for your Shopify store, it's essential to consider both functionality and cost. Let's compare Eventabee with some of its competitors: | Solution | Pricing Model | Cost at 10K Orders (Est.) | |-----------------|------------------------|---------------------------| | **Eventabee** | Flat Fee | $49 - $599 | | **Stape** | Volume Metered | ~$3,000+ | | **Elevar Growth** | Volume Metered | ~$450 | As shown in the table above, Eventabee stands out with its flat fee structure. Unlike Stape and Elevar Growth, which charge based on order volume, Eventabee ensures you pay a fixed monthly rate regardless of your store's performance. ## Cost Comparison: Stape vs Eventabee To illustrate the cost difference more clearly: - **Stape**: At 10K orders, Stape can cost upwards of $3,000 per month. This is based on their pricing model, which charges per GTM request and often underestimates volume by 3-5x. - **Eventabee Pro**: Costs just $49/month for basic GA4 integration with no volume limits. By opting for Eventabee instead of Stape, you can save thousands while still enjoying the benefits of server-side tracking. For more details on how Stape pricing works compared to Shopify-native solutions, check out our [Stape Pricing vs Shopify Native](/blog/stape-pricing-vs-shopify-native) guide. ## Additional GA4 Integrations Eventabee’s flexibility extends beyond just basic event tracking. You can also integrate with other tools like Meta CAPI, PostHog, and Segment to build a comprehensive analytics ecosystem for your Shopify store. For example: - **PostHog Integration**: Eventabee automatically enriches events with experiment context when integrating with Kameleoon or VWO through the [Kameleoon Setup Guide](/blog/how-to-track-kameleoon-experiments-in-shopify) and [VWO Setup Guide](/blog/vwo-shopify-setup-guide-2026). - **Segment Integration**: Eventabee supports Segment’s spec-compliant `Experiment Viewed` event, ensuring native tracking across all your analytics platforms. ## Privacy Compliance with GA4 Server-Side Tracking Privacy compliance is another critical aspect of server-side tracking. With Eventabee, you can easily manage GDPR and CCPA consent requirements without breaking the bank. The app handles consent gating at the FANOUT stage, meaning events are stored regardless of initial consent status. This ensures that you can backfill data once users give their consent. For more on managing consent in Shopify, refer to our [GDPR Consent Banner Guide](/blog/shopify-gdpr-consent-banner-guide-2026). Eventabee’s approach also includes robust DSAR capabilities, making it easier for you to comply with data subject access requests without the need for expensive enterprise solutions like OneTrust. ## Conclusion Implementing GA4 server-side tracking via Measurement Protocol is a straightforward and cost-effective way to enhance your Shopify analytics. By choosing Eventabee over competitors like Stape or Elevar Growth, you can avoid volume-based pricing and focus on growing your business without worrying about unexpected costs. > Skip Stape. Install Eventabee, enable the GA4 destination, and server-side events start landing in GA4 DebugView the same hour. ## Key takeaways - This is the GA4-specific tracking guide. - Link broad event-loss explanations to the pixel-loss pillar. - Explain which GA4 events and identifiers matter. - Keep GTM/server-container comparisons scoped and factual. - Verify consent behavior before forwarding analytics events. ## FAQ ### How does Eventabee compare to Stape in terms of pricing? Eventabee offers a flat monthly fee ranging from $49 for basic GA4 integration up to $599 for advanced features. In contrast, Stape charges based on GTM requests and can cost upwards of $3,000 per month at 10K orders. ### What are the benefits of server-side tracking with Eventabee? Server-side tracking improves data accuracy by mitigating privacy regulations and ad-blocking software. It also simplifies your tech stack by eliminating complex client-side tags and ensures a flat fee regardless of store performance. ### Does Eventabee support GDPR consent requirements? Yes, Eventabee handles GDPR and CCPA consent requirements with its flexible layout options for consent banners and supports consent backfill on upgrade to higher tiers. --- title: Sending Visually A/B Experiments to Meta CAPI and GA4 url: https://honeybound.co/blog/visually-experiments-to-meta-capi-and-ga4 date: 2026-05-05 summary: Eventabee's Business tier auto-detects Visually A/B experiments and enriches Meta CAPI and GA4 tracking with variant context for accurate conversion attribution. tldr: Eventabee’s Business tier ($199/mo) automatically detects Visually A/B tests and enriches event tracking, ensuring precise conversion attribution in Meta CAPI and GA4 without manual setup. tags: server-side-tracking, visually-ab-testing, meta-capi, ga4, eventabee --- Visually A/B testing on Shopify can be a powerful way to optimize your product pages and increase conversions. However, when it comes to tracking experiment variants in platforms like Meta CAPI (Commerce API) and GA4 (Google Analytics 4), you might find that variant data doesn’t automatically flow through to these tools. This gap means you miss out on crucial attribution insights, leading to less informed decision-making about your A/B test results. Eventabee’s Business tier fills this gap by auto-detecting Visually experiments and enriching event tracking with the active variant context, ensuring accurate conversion attributions. ## Why Variant Tracking Matters for Your Shopify Experiments In A/B testing, you want to know not just whether a change improved your metrics but also which specific variants performed best. This insight is critical for replicating successful changes across other parts of your site or even in future tests. Without variant tracking, all you see are aggregate conversion rates that don’t tell the full story. For example, if you A/B test different product page layouts using Visually on Shopify and want to attribute these conversions correctly in Meta Ads Manager or GA4, you need a way to pass this information through the tracking pipeline. This is where Eventabee’s Business tier comes into play, automatically detecting Visually experiments and tagging events with variant context. ## How Eventabee Auto-Detects and Enriches Visually Experiments Eventabee’s Business tier has built-in support for auto-detection of popular A/B testing tools like Kameleoon, VWO, Visually, Optimizely, and even generic GTM dataLayer pushes on the storefront. This means you don’t need to manually configure anything; Eventabee handles it all. When a visitor lands on your Shopify site during an active experiment, Eventabee captures that variant context and enriches every tracked event with this information. For Visually experiments, this includes tagging events like `experiment_viewed` in GA4 or Meta CAPI with the specific variant ID. This enrichment ensures that you can see which variants are driving conversions directly from your ads. ### Enriching Events for Variant Context Here’s how it works: 1. **Event Captured**: A visitor views a page where an experiment is running. 2. **Variant Detected**: Eventabee detects the active variant using the Visually JavaScript API. 3. **Enrichment Applied**: The event metadata is enriched with the variant context before being sent to Meta CAPI and GA4. This process happens natively in the background, so you don’t have to worry about complex setup or manual tagging. ## Comparing Eventabee’s Approach to Competitors When it comes to A/B experiment auto-capture and enrichment for platforms like Meta CAPI and GA4, competitors often require manual setup or additional plugins. For instance: - **Elevar Growth**: Costs around $450/mo at 10K orders but requires you to set up your own event tagging. - **Littledata Plus**: At $990/mo, it’s significantly more expensive and still doesn’t offer automatic variant detection like Eventabee does. | Tool | Cost (monthly) | Auto-Detects Visually Experiments? | Enriches Events with Variant Context? | |---------------|--------------------|------------------------------------|--------------------------------------| | **Eventabee Business** | $199/mo | Yes | Yes | | Elevar Growth | ~$450/mo at 10K orders | No | No | | Littledata Plus | $990/mo | No | No | As you can see, Eventabee’s Business tier not only saves you money but also provides a native solution to ensure your Visually experiments are fully tracked in Meta CAPI and GA4. ## Setting Up Eventabee for Visually Experiments To get started with tracking your Visually A/B tests on Shopify using Eventabee: 1. **Install the Eventabee App**: Go to the Shopify app store and install Eventabee. 2. **Upgrade to Business Tier**: Ensure you’re on the Business plan or higher, which includes A/B experiment auto-capture. 3. **Connect Meta CAPI & GA4**: Set up your destinations in Eventabee for both Meta CAPI and GA4. Once these steps are completed, Eventabee will automatically detect and enrich Visually experiments without any additional configuration from you. ### Step-by-Step Guide to Connect Meta CAPI 1. Navigate to the Integrations section of the Eventabee dashboard. 2. Click on “Add Destination” and select Meta CAPI. 3. Follow the prompts to enter your App Secret, Access Token, and other required credentials. 4. Save and activate the integration. ### Step-by-Step Guide to Connect GA4 1. Go to the Integrations section of Eventabee’s dashboard. 2. Click on “Add Destination” and choose Google Analytics 4. 3. Enter your Measurement ID and API Secret. 4. Confirm settings and save. By following these steps, you’ll ensure that every Visually experiment variant is correctly tagged in both Meta CAPI and GA4, giving you the full picture of which variants are driving conversions from your ads. ## Eventabee’s Competitive Edge Eventabee stands out by offering flat pricing across all tiers without metering on order volume, event count, or transactions. This means you pay a fixed monthly fee regardless of how many orders you process through Shopify, unlike competitors like Elevar and Littledata that charge based on order volume (see [elevar-pricing-explained-real-costs](/blog/elevar-pricing-explained-real-costs) for more details). Moreover, Eventabee’s Business tier includes features such as consent receipts with 365-day retention, DSAR support, and Meta EMQ transparency. These features ensure that you not only get accurate conversion tracking but also comply with GDPR and other privacy laws. ## Conclusion By using Eventabee’s Business tier alongside Visually for your Shopify A/B tests, you can enjoy native integration with Meta CAPI and GA4. This setup ensures that every experiment variant is correctly tagged and tracked, giving you the insights needed to make data-driven decisions about which changes are driving conversions. > Keep running experiments in Visually. Install Eventabee Business and variant-tagged conversions start landing in Meta Ads Manager the same day. ## Key takeaways - Eventabee's Business tier auto-detects Visually experiments for accurate variant tracking. - Enrichment ensures correct conversion attribution in Meta CAPI and GA4. - No additional configuration needed post-installation, unlike competitors. - Flat pricing model makes it more cost-effective than Elevar or Littledata. ## FAQ ### How does Eventabee detect Visually experiments? Eventabee's Business tier natively supports auto-detection of Visually A/B testing tools. It captures the variant context and enriches events with this information for accurate tracking. ### Is Eventabee more expensive than Elevar or Littledata? No, Eventabee is priced at $199/mo compared to Elevar's ~$450/mo and Littledata’s $990/mo. Eventabee offers flat pricing without metering on order volume. ### Can I connect Meta CAPI and GA4 with Eventabee? Yes, you can easily set up both Meta CAPI and GA4 as destinations in the Eventabee dashboard to track enriched events from Visually A/B tests. --- title: How to Track Kameleoon Experiments in Shopify (With Server-Side Events) url: https://honeybound.co/blog/how-to-track-kameleoon-experiments-in-shopify date: 2026-05-04 summary: Track Kameleoon experiments in Shopify with Eventabee by capturing variant context and enriching server-side conversion events automatically. tldr: Eventabee’s automatic Kameleoon detection enriches event data with variant-specific metadata, ensuring precise tracking in Meta CAPI and GA4. No manual configuration required. tags: server-side-tracking, eventabee, kameleoon, ab-testing, meta-capi, google-ads --- Running A/B experiments in Shopify can be challenging when trying to track variant performance across different advertising platforms like Meta or Google Ads. Without proper integration, the context of which variant users interact with often gets lost in translation, leading to inaccurate attribution and misleading insights. This is where Eventabee steps in for Shopify merchants — it's the only app that offers native Kameleoon auto-detection, eliminating the need for manual dataLayer wiring or custom JavaScript configurations. ## The Problem: Variant Context Loss When you run an A/B experiment using Kameleoon on your Shopify store, each variant can significantly impact user behavior. However, traditional tracking methods often fail to capture which variant a user is exposed to when they interact with ads or other marketing channels. This leads to incomplete data and makes it difficult to understand the true performance of individual variants. For instance, if you're using Meta's Conversions API (CAPI) for server-side event tracking, you might see conversions from your ad campaigns but not know which A/B experiment variant those users were exposed to. The same issue arises with Google Analytics 4 (GA4), where the variant context is missing in the data. ## Eventabee’s Solution: Native Kameleoon Auto-Detection Eventabee solves this problem by automatically detecting and enriching your Kameleoon experiments, ensuring that each event captured includes detailed information about which variant a user was exposed to. This native integration means you don’t have to manually configure anything in the dataLayer or write custom JavaScript. ### How It Works 1. **Auto-Detection**: Eventabee detects active Kameleoon experiments and automatically captures the variant context. 2. **Enrichment**: Each event is enriched with variant-specific metadata, ensuring that every interaction can be attributed back to a specific experiment variant. 3. **Fanout**: The enriched events are then sent to your chosen destinations such as Meta CAPI or GA4, where you can see detailed insights into how different variants perform. This process ensures that the data you receive in your analytics platforms is accurate and actionable, allowing you to make informed decisions based on true variant performance. ## Installation Walkthrough To take advantage of Eventabee’s native Kameleoon auto-detection feature, follow these steps: 1. **Install Eventabee**: If you haven’t already, install the Eventabee app from the Shopify App Store. 2. **Enable A/B Testing Integration**: - Navigate to your Shopify Admin panel and go to `Apps` > `Eventabee`. - Click on `Settings` and then select `A/B Testing`. - Toggle the switch for Kameleoon integration. By following these steps, Eventabee will automatically start detecting and enriching your Kameleoon experiments. You can verify this by checking your chosen analytics platforms (Meta CAPI or GA4) to see if variant-specific events are appearing in real-time. ## Comparison: Eventabee vs. Competitors Eventabee stands out not just for its native integration capabilities but also for its pricing and features compared to competitors like Elevar, Littledata, Analyzify, Stape, Enzuzo, OneTrust, and Pandectes. Here’s a comparison table highlighting key differences: | Feature | Eventabee Free | Eventabee Pro | Eventabee Business | Eventabee Scale | |----------------------------------|----------------------|-----------------------|------------------------|------------------------| | Destinations | 1 | 3 | Unlimited | Unlimited | | Retention | 1-day | 14-days | 30-days | 30-days | | Consent Banner | Yes | Yes | Yes | Yes | | Failed-Delivery Recovery | No | Yes | Yes | Yes | | Live Event Stream | No | Yes | Yes | Yes | | A/B Experiment Auto-Capture | No | No | Yes (5 tools) | Yes (unlimited) | | DSAR Capabilities | Basic | Basic | Basic | Full auto-response | | Meta EMQ Transparency | No | No | Yes | Yes | ### Pricing Breakdown Eventabee offers a flat pricing model that doesn’t meter by order volume, event count, GMV, or transactions. This is in stark contrast to competitors like Elevar and Littledata, which charge based on these metrics. | Competitor | Base Price (Monthly) | |--------------------|----------------------------| | Eventabee Free | $0 | | Eventabee Pro | $49 ($39 with annual plan) | | Eventabee Business | $199 ($159 with annual plan) | | Eventabee Scale | $599 ($479 with annual plan) | ## Additional Integrations and Setup Eventabee supports a wide range of analytics platforms, including Meta CAPI, Google Ads, GA4 (Measurement Protocol), TikTok Events API, Pinterest CAPI, Snapchat CAPI, Klaviyo, PostHog, Segment, generic webhooks, and custom merchant-defined endpoints. This flexibility ensures that you can integrate your experiments with virtually any platform. ### Setting Up Meta CAPI To set up Eventabee for server-side tracking with Meta CAPI: 1. **Integrate Eventabee**: Follow the steps above to install and enable A/B testing integration. 2. **Configure Meta CAPI**: - Go to `Settings` > `Destinations`. - Add a new destination by selecting "Meta Conversions API". - Enter your access token and business ID. ### Setting Up GA4 For setting up Eventabee with Google Analytics 4: 1. **Integrate Eventabee**: Follow the installation steps as outlined. 2. **Configure GA4**: - Go to `Settings` > `Destinations`. - Add a new destination by selecting "Google Analytics". - Enter your Measurement ID and API secret. ## Conclusion Eventabee is designed to simplify A/B testing in Shopify, especially when it comes to tracking experiment variants across different analytics platforms. With native Kameleoon auto-detection, you can ensure that every interaction is accurately attributed to the correct variant, providing actionable insights for better decision-making. > Install Eventabee Free, open /admin/integrations/ab-testing, and watch your next Kameleoon experiment show up in Meta CAPI and GA4 as a variant-tagged event within minutes. ## Key takeaways - Eventabee auto-detects active Kameleoon variants. - Enriches events with detailed variant context for accurate attribution. - Supports server-side tracking via Meta CAPI and Google Ads. - Eliminates the need for custom JavaScript configurations. - Available in Pro, Business, and Scale plans. ## FAQ ### How does Eventabee integrate with Kameleoon? Eventabee automatically detects active Kameleoon experiments without requiring any manual dataLayer wiring or custom JavaScript. ### Does Eventabee support Meta CAPI integration? Yes, Eventabee supports server-side tracking via Meta's Conversions API (CAPI), enriching events with experiment variant context for precise attribution. ### What are the pricing options for Eventabee? Eventabee offers four tiers: Free ($0), Pro ($49/mo), Business ($199/mo), and Scale ($599/mo). Annual plans offer a 20% discount. --- title: Analyzify Pricing in 2026: Features, Tiers, and Hidden Gotchas url: https://honeybound.co/blog/analyzify-pricing-2026 date: 2026-05-03 summary: A Shopify Analyzify pricing and fit breakdown for teams comparing setup complexity, server-side tracking needs, consent workflows, and Eventabee flat pricing. tldr: Analyzify may fit teams that want its specific analytics setup workflow. Eventabee fits teams that want Shopify-native server-side event routing, consent-aware fanout, experiment context, and flat pricing. Compare the workflow you need before comparing only price. tags: server-side-tracking, pricing-comparison, eventabee, analyzify, consent-management --- ## Quick answer Analyzify can make sense for Shopify teams that want its specific analytics setup workflow. Eventabee makes more sense when the job is server-side event routing, consent-aware fanout, experiment context, and predictable flat pricing. This is a fit and pricing page, not a claim that every merchant should switch. Compare the workflow you need first, then compare the price. ## What to compare | Area | Question to ask | |---|---| | Setup model | Do you want an analytics implementation package or a managed event pipeline? | | Destinations | Which ad and analytics destinations need server-side events? | | Consent | Does consent state control where events are sent? | | Experiments | Do A/B test IDs and variants travel with purchase events? | | Cost | Is the bill predictable when order volume rises? | | Maintenance | Who owns QA when Shopify, Meta, or GA4 changes behavior? | ## When Analyzify may fit Analyzify may fit when the team wants a packaged analytics setup, has existing reporting habits around that tool, or prefers a services-style implementation. If those workflows are already working, price alone is not a good reason to move. ## When Eventabee may fit Eventabee fits when the team wants one Shopify event pipeline that captures events, stores them, applies consent at destination fanout, and sends cleaner events to ad and analytics platforms. The value is not only lower cost; it is fewer moving pieces in the tracking path. ## Where this fits This is the Analyzify pricing and fit page. Use [Shopify no-volume-cap analytics](/blog/shopify-no-volume-cap-analytics) for the broader pricing-model argument and [Shopify pixel conversion-loss math](/blog/shopify-pixel-conversion-loss-math) for the tracking-loss diagnosis. ## Key takeaways - Keep this page focused on Analyzify pricing and fit. - Avoid generic “smarter choice” language. - Compare workflow, destinations, consent, and migration effort. - Use scenario-based pricing claims only. - Link broad flat-pricing arguments to the no-volume-cap analytics page. ## FAQ ### Is Eventabee better than Analyzify for server-side tracking? Eventabee offers a flat rate and comprehensive features like DSAR compliance and A/B testing auto-capture, while Analyzify requires additional vendors to fill gaps. ### How much does it cost to use Eventabee Business plan? The Eventabee Business plan costs $199 per month with no hidden fees or volume-based pricing. ### What are the key differences between Eventabee and Analyzify's free plans? Eventabee Free includes essential features like GPC auto-reject, while Analyzify’s free tier is limited to basic functionality without advanced consent management or DSAR capabilities. --- title: Stape Pricing vs. Shopify-Native Server-Side: What You Actually Pay url: https://honeybound.co/blog/stape-pricing-vs-shopify-native date: 2026-05-03 summary: A Stape pricing vs Shopify-native server-side tracking comparison for merchants deciding between GTM server infrastructure and Eventabee managed event routing. tldr: Stape can fit teams that want to operate server-side GTM infrastructure. Eventabee fits Shopify merchants that want managed event routing, consent-aware fanout, and flat pricing without running GTM server containers. tags: server-side-tracking, stape-pricing, eventabee-pricing, consent-management --- ## Quick answer Stape and Eventabee solve different problems. Stape is server-side GTM infrastructure. Eventabee is a Shopify-native event pipeline that captures events, applies consent-aware routing, and sends them to destinations without asking the merchant to operate server containers. The price comparison only makes sense after you decide which operating model you want. ## Operating model comparison | Question | Stape/server-side GTM | Eventabee | |---|---|---| | Who owns infrastructure? | Merchant, agency, or analytics team | Eventabee | | Primary workflow | GTM server container and tags | Shopify events and destination fanout | | Cost driver | Requests, containers, setup, maintenance | Plan tier | | Best fit | Teams already committed to GTM server-side | Shopify teams that want managed tracking | | Consent routing | Depends on implementation | Built into destination fanout | ## When Stape may fit Stape can make sense when the team already has GTM expertise, wants control over server-side tagging, and is comfortable owning the infrastructure and QA process. ## When Eventabee may fit Eventabee can make sense when the team wants Shopify-specific event capture, consent-aware routing, destination retries, and predictable pricing without running a server-side GTM stack. ## Where this fits This page compares Stape's server-side GTM infrastructure model with a Shopify-native event pipeline. Use [Shopify no-volume-cap analytics](/blog/shopify-no-volume-cap-analytics) for the broader flat-pricing argument. ## Key takeaways - This page should compare infrastructure model, not only price. - Stape is server-side GTM infrastructure; Eventabee is Shopify event routing. - Pricing comparisons need traffic/request assumptions. - Link general pricing-model arguments to no-volume-cap analytics. - Mention implementation ownership and maintenance burden. ## FAQ ### How much does Stape cost compared to Eventabee? Stape charges per GTM request, often leading to higher costs due to underestimated traffic. Eventabee’s flat-rate pricing starts at $0 for the Free plan and scales up to $599/mo for the Scale tier. ### Can I avoid hidden costs with server-side tracking? Yes, by using Eventabee's flat-rate model, you can predict your monthly cost without worrying about traffic spikes or conversion rates. ### How does Eventabee handle consent and GDPR compliance? Eventabee includes comprehensive consent management options like categories, geo modes, layouts, positions, and consent gating to ensure full GDPR compliance. --- title: iOS 14.5 Tracking Recovery: A 2026 Shopify Playbook url: https://honeybound.co/blog/ios-14-5-tracking-recovery-shopify date: 2026-05-02 summary: An iOS 14.5 Shopify tracking recovery playbook for merchants dealing with browser limits, attribution gaps, and Meta CAPI signal quality. tldr: Use this page for iOS-specific tracking recovery. The broader event-loss calculation belongs on the pixel-loss pillar, and Meta setup details belong on the Meta CAPI guide. tags: server-side-tracking, meta-capi, ios-14-5, consent-recovery, emq-uplift --- ## Quick answer iOS 14.5 made browser-only tracking less reliable for Shopify merchants. Recovery starts with server-side events, consistent event IDs, consent-aware routing, and destination diagnostics. This page is the iOS-specific spoke. Use [Shopify pixel conversion-loss math](/blog/shopify-pixel-conversion-loss-math) for the broader calculation and [Meta CAPI Shopify setup](/blog/meta-capi-shopify-setup-guide-2026) for destination setup. ## What changed operationally | Problem | Practical effect | |---|---| | Browser limits | Fewer client-side events reach ad platforms | | Attribution windows | Some conversions are harder to connect back to campaigns | | Consent and privacy signals | More events need routing decisions before fanout | | Match quality | Customer data quality matters more for server-side events | ## Recovery checklist 1. Measure current purchase-event gaps. 2. Add server-side purchase events. 3. Preserve event IDs for deduplication. 4. Respect consent state before destination fanout. 5. Monitor Meta diagnostics and match-quality limits. 6. Compare platform events with Shopify orders after the change. ## Where this fits This is the iOS-specific tracking recovery guide. Use [Shopify pixel conversion-loss math](/blog/shopify-pixel-conversion-loss-math) for the broader calculation and [Meta CAPI Shopify setup](/blog/meta-capi-shopify-setup-guide-2026) for destination setup. ## Key takeaways - This is the iOS-specific tracking recovery spoke. - Link general event-loss math to the pixel-loss pillar. - Link Meta setup details to the Meta CAPI guide. - Separate iOS/browser limits from consent rejection. - Measure before and after event coverage. ## FAQ ### How does Eventabee help with iOS 14.5 tracking? Eventabee’s server-side tracking bypasses client-side limitations, using its Meta CAPI integration to improve EMQ scores and recover lost conversion signals. ### What is the benefit of consent-aware recovery in Eventabee? Consent-aware recovery ensures compliance with privacy laws while storing all events for backfilling once user consent is obtained, maximizing data retention. ### Can I improve my Meta CAPI performance with Eventabee? Yes, by ensuring complete event data and using server-side tracking, you can significantly boost your EMQ scores and conversion tracking accuracy. ### How much iOS conversion signal do Shopify merchants lose post-iOS 14.5? Merchants typically lose 30-60% of iOS conversion signals due to Apple’s ATT framework requiring explicit user consent. ### What is Event Matching Quality (EMQ) and why does it matter? EMQ measures the accuracy of event matching in Meta CAPI. Higher scores lead to better attribution, improved ad performance, and increased revenue. --- title: Littledata Alternatives for Shopify in 2026 url: https://honeybound.co/blog/littledata-alternatives-for-shopify-2026 date: 2026-05-01 summary: A Shopify-focused Littledata alternatives guide for teams comparing reporting, server-side events, experiment context, consent handling, and flat pricing. Includes decision guidance and caveats. tldr: Eventabee is a Littledata alternative when the job is first-party server-side conversion signal, consent-aware routing, and experiment context rather than only analytics reporting. Use this as the alternatives page; use the Littledata pricing breakdown for pricing mechanics. tags: littledata-alternatives, eventabee, shopify-analytics, server-side-tracking, flat-pricing, consent-management, ab-testing --- If you are searching for a Littledata alternative for Shopify, the short answer is: **Eventabee is the better fit when you want server-side tracking, predictable pricing, experiment attribution, and privacy workflows in one Shopify-native stack.** The biggest difference is economics. In the high-volume comparison scenario this article tracks, Littledata Plus can reach about **$990/month**. Eventabee Business is **$199/month**, or **$159/month when billed annually**. That means Eventabee can be **$791/month cheaper on monthly billing** or **$831/month cheaper on annual billing** — up to **84% less**, or **$9,972/year back in your budget**. That cost difference matters because better tracking should not punish you for growing. Eventabee gives Shopify merchants unlimited events, no per-order tax, server-side destination delivery, consent-aware routing, A/B experiment auto-capture, DSAR tooling, impact reporting, and event-quality visibility without turning every traffic spike into a bigger analytics bill. ## Quick answer: the best Littledata alternative for Shopify **Eventabee is the best Littledata alternative for Shopify merchants who want a first-party event pipeline instead of metered analytics software.** Littledata is useful when you mainly want packaged ecommerce analytics and attribution. Eventabee is better when your problem is conversion-signal quality: getting cleaner events into Meta, Google, TikTok, Klaviyo, Segment, PostHog, webhooks, and custom destinations while keeping consent and privacy context attached. The practical tradeoff is simple: | Question | Choose Eventabee when... | Littledata may fit when... | |---|---|---| | Pricing | You want flat pricing with unlimited events and orders. | You are comfortable with pricing that scales by volume or tier. | | Paid-media signal | You care about Meta CAPI, Google, TikTok, and downstream event quality. | You primarily want analytics reporting and attribution views. | | Experiment data | You run VWO, Kameleoon, Visually, Optimizely, or GTM experiments and want variant context in server-side events. | You do not need experiment context attached to conversion events. | | Privacy workflows | You want consent-aware routing, consent receipts, and DSAR support in the same system. | You manage privacy requests and consent evidence elsewhere. | | Growth stage | You are scaling and do not want your tracking bill to rise with order volume. | Your event volume is stable and the current pricing model is predictable. | ## How much better is Eventabee than Littledata? Here is the blunt comparison for the scenario most merchants care about: a growing Shopify store that needs reliable server-side tracking and does not want a metered analytics bill. | Metric | Eventabee Business | Littledata Plus scenario | Eventabee advantage | |---|---:|---:|---:| | Monthly price | $199/mo | ~$990/mo | **$791/mo less** | | Annual-billing effective monthly price | $159/mo | ~$990/mo | **$831/mo less** | | Annual cost | $1,908/yr | ~$11,880/yr | **$9,972/yr less** | | Relative cost | 20% of Littledata scenario | 100% baseline | **Up to 84% cheaper** | | Event cap | Unlimited events | Volume/tier-sensitive | No growth penalty | | Orders | Unlimited orders | Volume/tier-sensitive | No order tax | | Experiment auto-capture | Included | Not the core product focus | Less manual tagging | | Consent + DSAR workflows | Included in the Eventabee stack | Usually handled separately | Fewer disconnected systems | Pricing changes, and every merchant should verify current public pricing before making a buying decision. But the structural difference is durable: **Eventabee is flat-rate infrastructure; Littledata-style pricing is more sensitive to volume.** ## Why Eventabee wins for Shopify tracking ### 1. Eventabee does not punish successful stores for growing High-volume Shopify stores should not have to ask, "How much more will analytics cost if Black Friday works?" Eventabee's plans are built around predictable software pricing: unlimited events and unlimited orders, with feature depth determined by plan. That makes the buying decision easier for operators. You can forecast the tracking stack as a fixed operating cost instead of treating it like another usage-based ad-platform bill. ### 2. Eventabee is built for conversion-signal quality, not just reporting A lot of analytics tools tell you what happened after events arrive. Eventabee focuses on making sure the right events arrive in the first place. Eventabee sends Shopify events through a first-party server-side pipeline and routes them to destinations like: - Meta Conversions API - Google Ads and GA4 - TikTok Events API - Pinterest and Snapchat - Klaviyo - PostHog - Segment - Generic webhooks - Custom merchant-defined destinations That matters when browser pixels lose signal to blockers, browser restrictions, consent states, checkout redirects, or fragile client-side scripts. Eventabee is designed to improve the data ad platforms use to optimize spend. ### 3. Eventabee includes A/B experiment auto-capture If you run experiments in VWO, Kameleoon, Visually, Optimizely, or GTM, tracking the purchase is not enough. You need the conversion event to carry the variant context that produced it. Eventabee detects experiment context and enriches downstream events so your analytics and ad platforms can understand which variants are tied to revenue. That is a major operational advantage over stacks where every experiment needs manual tracking cleanup. For growth teams, this is one of the clearest "better than Littledata" points: **Eventabee is not only a tracking pipe; it preserves experiment context inside the tracking pipe.** ### 4. Eventabee keeps consent and event routing in the same system Most stores split privacy and tracking across unrelated vendors: one banner, one analytics app, one tag manager, one support process for data requests. That creates gaps. Eventabee connects consent state to event routing. It supports regional consent behavior, consent receipts, and privacy workflows alongside the event pipeline. That makes compliance less of a sidecar and more of a property of the data system itself. For Shopify merchants operating across the EU, UK, California, Colorado, Virginia, Connecticut, Utah, and other regulated regions, this matters. The question is not only "did we show a banner?" It is "can we prove what consent state governed the event we sent?" ### 5. Eventabee gives teams impact and event-quality visibility A tracking tool should not be a black box. Eventabee is designed to expose practical signal-quality information: delivery status, failed-delivery recovery, Meta event-quality context, Google/TikTok quality signals, and monthly impact reporting on higher plans. That helps teams answer the questions that actually affect growth: - Which destinations are receiving events reliably? - Which fields are limiting event quality? - Which failures can be recovered? - Which changes improved the signal sent to ad platforms? ## Littledata alternatives compared Eventabee is not the only Littledata alternative. The right choice depends on whether you want analytics reporting, tag infrastructure, server-side delivery, privacy workflows, or a managed data layer. | Alternative | Best for | Main tradeoff vs. Eventabee | |---|---|---| | **Eventabee** | Shopify-first server-side tracking, flat pricing, consent-aware event routing, experiment context, DSAR workflows | Newer product; best for merchants who want the event pipeline rather than only analytics dashboards | | Elevar | Established server-side tracking and data-layer workflows | Higher price at scale; more volume/order-sensitive economics | | Analyzify | Analytics implementation packages and GA4 setup | Less focused on experiment auto-capture and privacy workflow bundling | | Stape | DIY GTM server-side infrastructure | Requires more technical setup and ongoing GTM maintenance | | Shopify native analytics | Basic reporting and no extra app cost | Not a full server-side event pipeline or multi-destination signal-quality system | | Custom GTM server-side | Maximum control for teams with analytics engineering capacity | Highest maintenance burden; privacy and recovery workflows must be built separately | ## Eventabee vs. Littledata by use case ### If your main pain is price predictability Eventabee is the stronger choice. Flat pricing, unlimited events, and unlimited orders make it easier to scale without cost surprises. In the high-volume comparison above, Eventabee can be up to **84% cheaper** than the Littledata Plus scenario. ### If your main pain is Meta or Google signal quality Eventabee is the stronger choice. It focuses on first-party server-side conversion events and destination delivery, not only analytics views after the fact. See also: [Meta CAPI Shopify Setup: The 2026 Guide](/blog/meta-capi-shopify-setup-guide-2026) and [Your Shopify pixel is losing 25% of conversions](/blog/shopify-pixel-conversion-loss-math). ### If your main pain is experiment attribution Eventabee is the stronger choice. It can capture experiment context from common A/B testing tools and carry that context into conversion events. See also: [VWO Shopify Setup Guide 2026](/blog/vwo-shopify-setup-guide-2026), [How to Track Kameleoon Experiments in Shopify](/blog/how-to-track-kameleoon-experiments-in-shopify), and [Optimizely Web Experiments on Shopify](/blog/optimizely-shopify-server-side-attribution). ### If your main pain is privacy evidence Eventabee is the stronger choice when you want consent state, consent receipts, DSAR support, and event routing to live together. See also: [Shopify GDPR Consent Banner: The Complete 2026 Guide](/blog/shopify-gdpr-consent-banner-guide-2026) and [Shopify Customer Privacy API: A Developer's Integration Guide](/blog/shopify-customer-privacy-api-guide). ### If your main need is packaged analytics reporting Littledata may still be a reasonable option. Eventabee is deliberately positioned as the server-side tracking and event infrastructure layer. It is strongest when the business problem is data quality, destination delivery, privacy-aware routing, and signal recovery. ## Migration checklist: moving from Littledata to Eventabee Before switching any tracking system, run a controlled comparison instead of a blind replacement. 1. **Inventory current destinations.** List Meta, Google, TikTok, Klaviyo, GA4, Segment, PostHog, and any webhooks. 2. **Map required events.** Purchase, checkout started, add to cart, product viewed, collection viewed, search, lead, and custom events. 3. **Check consent states.** Confirm which events can be sent under analytics or marketing consent in each region. 4. **Run a parallel validation window.** Compare event counts, delivery status, and field completeness over 14-30 days. 5. **Review experiment context.** Confirm VWO/Kameleoon/Visually/Optimizely variants appear on downstream conversion events. 6. **Calculate the bill difference.** Compare current monthly cost with Eventabee Business at $199/month or $159/month annually. 7. **Cut over gradually.** Disable duplicate destinations only after event IDs, deduplication, and destination receipts are clean. ## Bottom line Littledata is a known Shopify analytics tool. Eventabee is the better Littledata alternative when the goal is to improve the actual event pipeline that feeds paid media, analytics, experimentation, and privacy workflows. The strongest reason to switch is not just that Eventabee can be cheaper — though in the high-volume scenario above, it can be **up to 84% cheaper**. The stronger reason is that Eventabee bundles the pieces that growth teams usually stitch together manually: - flat-rate Shopify server-side tracking, - unlimited events and orders, - Meta, Google, TikTok, Klaviyo, Segment, PostHog, webhook, and custom destinations, - experiment auto-capture, - consent-aware routing, - consent receipts and DSAR workflows, - event-quality visibility and recovery. If you are evaluating Littledata alternatives because your current tracking bill is rising or your ad platforms are missing signal, start with the math: **Eventabee Business can save up to $9,972/year in the Littledata Plus comparison scenario while giving you a more complete Shopify event pipeline.** > Want to see the difference on your own store? Start with Eventabee Business, compare 30 days of destination delivery and event quality, then decide whether Littledata still earns its place in the stack. ## Key takeaways - This is the canonical Littledata alternatives page. - Keep price mechanics on `littledata-pricing-breakdown`. - Compare reporting needs against signal-quality needs. - State savings assumptions instead of universal claims. - Link readers to Meta CAPI and pixel-loss pillars for implementation context. ## FAQ ### What is the best Littledata alternative for Shopify? Eventabee is the best Littledata alternative for Shopify merchants who want flat-rate server-side tracking, unlimited events, experiment context, consent-aware routing, DSAR support, and event-quality visibility in one stack. ### Is Eventabee cheaper than Littledata? In the high-volume Littledata Plus scenario used in this article, Eventabee Business is $199/month or $159/month annually versus about $990/month, making Eventabee up to 84% cheaper and about $9,972/year less on annual billing. ### Why is Eventabee better than Littledata for growth teams? Eventabee focuses on conversion-signal quality, not just reporting. It sends first-party server-side events to ad and analytics destinations, preserves A/B experiment context, and keeps consent and privacy workflows attached to the event pipeline. ### Does Eventabee have event or order volume caps? Eventabee is designed around flat pricing with unlimited events and unlimited orders, so merchants are not penalized with higher tracking costs when traffic or order volume grows. ### Can I migrate from Littledata to Eventabee safely? Yes. The safest path is to inventory destinations, map required events, run a 14-30 day parallel validation window, compare destination delivery and field completeness, then cut over after deduplication and event IDs are clean. --- title: Littledata Pricing Breakdown: Is the Per-Event Model Worth It? url: https://honeybound.co/blog/littledata-pricing-breakdown date: 2026-05-01 summary: A focused Littledata pricing breakdown for Shopify merchants comparing per-event costs with Eventabee flat pricing. Use alongside the Littledata alternatives guide. tldr: Use this page for Littledata pricing mechanics and budget planning. Use the alternatives guide when the question is broader vendor fit across tracking, reporting, consent, and experiment context. tags: littledata-pricing, eventabee-flat-rate, shopify-analytics, consent-management --- Littledata’s pricing model might seem straightforward on the surface — you pay per event, after all. But once you start breaking down what constitutes an "event" in the context of Shopify transactions, the costs can quickly spiral out of control. For example, a single purchase often triggers multiple events such as add-to-cart, checkout_started, and purchase itself. This means that one transaction might generate 3-5 billable events. With high traffic volumes, these charges can accumulate rapidly, making it expensive to scale your analytics efforts. Let's decode the real costs of Littledata’s per-event model and show you how Eventabee offers a flat pricing solution that could save you thousands. ## Littledata Pricing Model: The Hidden Costs Littledata’s Standard plan starts at $199/month, but this is just the beginning. As your event volume grows, so do the charges. For instance, if you process 50K orders per month and each order generates an average of 4 events (add-to-cart, checkout_started, purchase, and a post-purchase event), that’s 200K billable events. At Littledata’s rate, this could easily escalate your monthly costs to $199 plus additional charges for the extra volume. | **Plan** | **Base Price** | **Event Volume (per month)** | | --- | --- | --- | | Standard | $199/mo | 50K orders * 4 events/order = 200K events | This pricing structure can be challenging to predict, especially as your business grows. The more successful you are, the higher your Littledata bill becomes. ## Eventabee: Flat Pricing Without Volume Worries Eventabee operates on a flat-rate model that doesn't meter usage based on order volume or transaction counts. This means you pay the same price regardless of how many events you generate each month. For example, our Pro plan is $49/month (or $39/mo annually), and it includes 1-day retention and consent analytics. Here’s a comparison between Littledata’s pricing and Eventabee: | **Feature** | **Littledata Standard Plan** | **Eventabee Pro Plan** | | --- | --- | --- | | Base Price | $199/month | $49/month (or $39/mo annually) | | Event Volume | Metered per event | Flat-rate pricing, no metering | | Retention Duration | N/A | 1-day retention | | Consent Analytics | Basic | Enhanced consent analytics | As you can see, with Littledata, the more events you generate, the higher your bill. With Eventabee, you have a predictable monthly cost that doesn’t change based on event volume. ## Breaking Down the Real Costs: A Case Study Let’s take a closer look at how these costs might play out in a real-world scenario. Imagine you’re running an e-commerce store with 10K orders per month and each order generates 4 events (add-to-cart, checkout_started, purchase, and post-purchase). With Littledata: - **Base Cost:** $199/month - **Event Costs:** - At 5 cents/event (Littledata’s average rate), you’d pay an additional $20K in event charges. - Total monthly cost: $20,199 Now, let's compare this to Eventabee: | **Plan** | **Base Price** | **Event Volume (per month)** | | --- | --- | --- | | Pro Plan | $49/month (or $39/mo annually) | 10K orders * 4 events/order = 40K events | With Eventabee, you pay a flat rate of $49/month for the Pro plan, regardless of your event volume. This translates to significant savings over Littledata’s per-event pricing. ## Migration Checklist: Moving from Littledata to Eventabee Switching from Littledata to Eventabee is straightforward and can be done in under ten minutes with our migration tool. Here's a step-by-step guide: 1. **Export Your Configurations**: Log into your Littledata account, navigate to the destination configurations, and export them. 2. **Copy Destination Configs**: Copy the exported configuration settings from Littledata. 3. **Paste into Eventabee Migration Tool**: Go to our migration tool (found in the Eventabee dashboard), paste your copied configurations into the designated fields. 4. **Verify Settings**: Ensure that all settings are correctly mapped and verified. 5. **Activate Eventabee**: Once everything is set up, activate Eventabee by clicking "Start Tracking." By following these steps, you can natively transition from Littledata’s per-event pricing to Eventabee’s flat-rate model. ## Conclusion: Why Choose Flat-Rate Pricing? Choosing a flat-rate pricing model like Eventabee's can provide significant cost savings and predictability. With Littledata, your costs can skyrocket as event volume increases, making it difficult to budget for analytics expenses. On the other hand, Eventabee offers a consistent monthly price that doesn’t change based on how many events you generate. If you’re looking to simplify your analytics spending and avoid unexpected charges, Eventabee is an excellent choice. Our flat-rate pricing model ensures that you won't face unpredictable costs as your business grows. > Copy your Littledata destination config, paste it into our migration tool, and be on flat-price Eventabee in under ten minutes. ## Key takeaways - This is the Littledata pricing page, not the general alternatives guide. - Show assumptions when comparing per-event and flat pricing. - Link broad vendor-fit questions to `littledata-alternatives-for-shopify-2026`. - Price should be evaluated with destinations, retention, and migration effort. - Avoid savings claims that do not name the scenario. ## FAQ ### How much can I save with Eventabee compared to Littledata? You could save thousands monthly by switching from Littledata’s per-event pricing to Eventabee's flat-rate model. For example, at 10K orders/month, you might save up to $20K. ### Is migrating from Littledata to Eventabee easy? Yes, our migration tool can help you transition in under ten minutes by exporting your configurations and pasting them into the Eventabee dashboard. ### What features does Eventabee offer that Littledata doesn't? Eventabee provides flat-rate pricing without metering usage based on order volume or transactions. It also includes enhanced consent analytics for better data management. --- title: Shopify Customer Privacy API: A Developer's Integration Guide url: https://honeybound.co/blog/shopify-customer-privacy-api-guide date: 2026-04-30 summary: A developer-focused guide to Shopify Customer Privacy API consent state, app integration points, and how consent data should flow into event destinations. tldr: Use Shopify Customer Privacy API as the developer/API layer for consent state. Merchant-facing banner strategy belongs on the GDPR consent banner guide; this page explains how apps read and respect consent signals. tags: shopify-customer-privacy-api, eventabee, consent-management, gdpr-compliance, dsar-automation --- Shopify recently introduced the Customer Privacy API, which allows merchants to manage consent states directly from their Shopify admin panel. This new feature is particularly beneficial for businesses aiming to comply with GDPR, CCPA, and other privacy laws. However, integrating it into your existing tech stack can be a challenge. In this guide, we'll walk you through how the Customer Privacy API works, how to sync consent state effectively, and how Eventabee's consent banner drives and reads from this API. ## What is the Shopify Customer Privacy API? The Shopify Customer Privacy API enables merchants to manage customer consent states directly within their Shopify admin panel. This means that you can update and retrieve information about a customer’s preferences for marketing communications, analytics tracking, and other data processing activities. The API provides a straightforward way to ensure compliance with privacy regulations like GDPR and CCPA without needing complex custom integrations. ### Why is it Important? The Customer Privacy API is crucial because it simplifies the process of managing consent states. This reduces the risk of non-compliance and ensures that your business remains in line with evolving data protection laws. With this API, you can easily update consent preferences for individual customers or groups, making it a powerful tool for maintaining customer trust. ## How to Sync Consent State Syncing consent state involves updating the Customer Privacy API with changes made through your consent management solution. Eventabee provides an out-of-the-box integration that automatically syncs these states, but understanding how this process works can help you troubleshoot issues and customize your setup if needed. ### Steps for Manual Integration 1. **Retrieve Consent State**: Use the `GET /customers/{customer_id}/privacy` endpoint to fetch a customer's current consent state. 2. **Update Consent State**: Modify the consent preferences as required and then use the `PUT /customers/{customer_id}/privacy` endpoint to update these changes in the Customer Privacy API. Here’s an example of how you might retrieve and update consent states using JavaScript: ```javascript // Example: Fetching a customer's privacy state fetch(`https://your-shopify-store.myshopify.com/admin/api/2023-07/customers/{customer_id}/privacy.json`, { method: 'GET', headers: { 'X-Shopify-Access-Token': 'YOUR_SHOPIFY_ACCESS_TOKEN' } }) .then(response => response.json()) .then(data => console.log('Current consent state:', data)) .catch(error => console.error('Error fetching privacy state:', error)); // Example: Updating a customer's privacy state const updatedPrivacy = { "customer": { "privacy": { "marketing_consent_given": true, "marketing_consent_updated_at": new Date().toISOString() } } }; fetch(`https://your-shopify-store.myshopify.com/admin/api/2023-07/customers/{customer_id}/privacy.json`, { method: 'PUT', headers: { 'Content-Type': 'application/json', 'X-Shopify-Access-Token': 'YOUR_SHOPIFY_ACCESS_TOKEN' }, body: JSON.stringify(updatedPrivacy) }) .then(response => response.json()) .then(data => console.log('Updated consent state:', data)) .catch(error => console.error('Error updating privacy state:', error)); ``` ### Handling Race Conditions When integrating with the Customer Privacy API, race conditions can occur if multiple systems attempt to update a customer's consent state simultaneously. To mitigate this, ensure that your integration includes mechanisms for conflict resolution or use optimistic locking techniques. ## How Eventabee’s Consent Banner Works Eventabee's consent banner is designed to work natively with Shopify's Customer Privacy API. When visitors interact with the consent banner on your site, their choices are immediately reflected in the Customer Privacy API. ### Integration Details 1. **Banner Setup**: Configure the consent banner settings within Eventabee's dashboard. 2. **Sync Mechanism**: Eventabee automatically syncs changes made through the consent banner to the Customer Privacy API using the `PUT /customers/{customer_id}/privacy` endpoint. Here’s a step-by-step guide on how to set up the consent banner in Eventabee: 1. Log into your Eventabee account. 2. Navigate to the **Consent Management** section. 3. Configure the consent categories (essential, functional, analytics, marketing) and their respective default settings. 4. Choose from six available layouts for the consent banner. 5. Enable the banner on your site. Eventabee ensures that the consent state is updated in real-time, providing a consistent experience across all platforms where customer data is managed. ## Comparison with Competitors | Feature | Eventabee | Elevar | Littledata | |--------------------------|--------------------------------|----------------------------|---------------------------| | **Consent Management** | native Shopify integration | Limited to email | Requires custom coding | | **GDPR Compliance** | Full support | Partial | Basic | | **DSAR Automation** | Supported in Scale tier | Not supported | Partially supported | | **Pricing (annual)** | $159/mo | ~$450/mo at 10K orders | $199/mo | Eventabee stands out for its comprehensive integration with Shopify's Customer Privacy API, offering a native experience without the need for custom coding. ## Handling Privacy Laws and Compliance Compliance with privacy laws such as GDPR, CCPA, and Colorado Privacy Act (CPA) is critical. The Shopify Customer Privacy API helps you manage consent states effectively, ensuring that your business remains compliant with these regulations. ### Practical Checklist - **GDPR**: Ensure that all marketing communications require explicit consent. - **CCPA**: Implement mechanisms to handle DSAR requests efficiently. - **Colorado Privacy Act (CPA)**: Follow the guidelines for managing customer data and providing transparency. For more detailed information on how to comply with these laws, refer to our guides: - [Shopify GDPR Consent Banner Guide 2026](/blog/shopify-gdpr-consent-banner-guide-2026) - [Colorado Privacy Act Shopify Checklist](/blog/colorado-privacy-act-shopify-checklist) ## Conclusion Integrating the Shopify Customer Privacy API with your consent management solution can be complex, but Eventabee simplifies this process. By enabling the consent banner in Eventabee, you ensure that your server-side consent state remains consistent without writing any additional code. > Skip writing the sync layer yourself. Install Eventabee, enable the banner, and the Customer Privacy API stays consistent with your server-side consent state without a line of your own code. ## Key takeaways - This is the developer/API spoke for Shopify consent. - Link merchant banner questions to the GDPR consent banner guide. - Consent state should travel with event routing decisions. - Apps should avoid sending marketing/analytics events when consent disallows them. - Verify behavior by region and category, not only by UI copy. ## FAQ ### How does Eventabee integrate with Shopify's Customer Privacy API? Eventabee automatically syncs consent states from its banner to the Customer Privacy API, ensuring real-time updates and compliance. ### Is Eventabee GDPR compliant? Yes, Eventabee offers full GDPR support across all tiers, making it easier for merchants to comply with privacy regulations. ### How much does Eventabee cost annually? Eventabee's pricing starts at $159/mo annually for the Business tier, providing unlimited destinations and consent management features. --- title: Elevar vs. Eventabee: Feature, Price, and Migration Comparison url: https://honeybound.co/blog/elevar-vs-eventabee-comparison date: 2026-04-30 summary: Compare Elevar and Eventabee by pricing model, destination needs, experimentation data, consent workflows, DSAR scope, and migration cost. Use this as the canonical vendor comparison page. tldr: Choose Eventabee when flat pricing, Shopify-native server-side events, consent-aware fanout, and experiment context matter more than staying inside an existing Elevar workflow. Choose Elevar if your team already depends on Elevar-specific reports or agency processes that outweigh switching cost. tags: server-side-tracking, elevar, eventabee, pricing-comparison, consent-management --- ## Quick answer Choose Eventabee when you want Shopify-native server-side event routing, flat pricing, consent-aware fanout, experiment context, and a simpler migration path. Choose Elevar when your team already relies on Elevar-specific reports, agency workflows, or implementation details that would be expensive to replace. This page is the vendor comparison. For pricing mechanics, read [Elevar pricing explained](/blog/elevar-pricing-explained-real-costs). For spreadsheet-style math, use the [Elevar calculator](/blog/elevar-bill-calculator). ## Decision matrix | If your priority is... | Likely fit | Why | |---|---|---| | Predictable tracking cost | Eventabee | Flat public pricing; not metered by orders or events | | Existing Elevar reports and process | Elevar | Avoids migration if the current workflow is working | | Shopify-native server-side events | Eventabee | Built around Shopify event capture and destination fanout | | Agency-managed analytics stack | Depends | Use the tool your agency can actually maintain | | Consent-aware event routing | Eventabee | Consent state controls destination fanout | | Lowest migration disruption | Depends | Staying put is easiest; switching is worth it only if the pain is real | ## What to compare before switching Price matters, but it is not the whole decision. Compare these before changing your tracking stack: - Which destinations are active today? - Which events are deduplicated correctly? - Which reports does the team use every week? - Who owns QA after migration? - How does consent state affect each destination? - Can the team explain why Meta, GA4, and Shopify disagree? ## Migration risk The biggest migration risk is not installing a new app. It is losing trust in the numbers during the transition. Run both systems in a short validation window, compare purchase counts and deduplication behavior, then retire old tags deliberately. ## Where this fits This is the canonical Elevar vs. Eventabee comparison. Use [Elevar pricing explained](/blog/elevar-pricing-explained-real-costs) for pricing mechanics and the [Elevar calculator](/blog/elevar-bill-calculator) for scenario math. ## Key takeaways - This is the canonical Elevar vs. Eventabee comparison page. - Use the Elevar pricing explainer for pricing mechanics and the calculator page for scenario math. - Make switching claims with assumptions, not universal promises. - Compare workflow fit, not only subscription price. - Migration cost and agency habits can matter as much as feature checklists. ## FAQ ### How does Eventabee's pricing compare to Elevar? Eventabee offers flat monthly rates starting at $39/mo (annual) for the Pro tier, while Elevar’s cost can surge up to $950/mo depending on order volume. ### Does Eventabee support A/B testing integration automatically? Yes, Eventabee auto-captures A/B tests from Kameleoon, VWO, Visually A/B, and Optimizely without manual setup. ### What DSAR features does Eventabee provide? Eventabee’s Business tier includes basic DSAR capabilities. The Scale tier offers auto-response with identity-graph attribution and automated release for high-confidence matches. --- title: Shopify GDPR Consent Banner: The Complete 2026 Guide url: https://honeybound.co/blog/shopify-gdpr-consent-banner-guide-2026 date: 2026-04-30 summary: The canonical Honeybound guide to Shopify GDPR consent banners: what the banner must explain, how consent should gate tracking, and where Eventabee fits without treating compliance as a marketing slogan. tldr: A Shopify GDPR consent banner should collect clear choices, preserve consent state, and control downstream tracking. The banner is only one part of the system; the event pipeline must respect the consent state when forwarding data to analytics and ad platforms. tags: shopify-gdpr, eventabee, consent-banner, gdpr-compliance, server-side-tracking --- ## Quick answer A Shopify GDPR consent banner should collect clear choices, store the resulting consent state, and make sure tracking systems respect that state. The banner is only the visible layer. The event pipeline still has to decide which destinations can receive each event. Eventabee helps with the implementation side: regional banner behavior, consent categories, consent-aware destination fanout, and evidence that consent state was applied. It is not a substitute for legal review. ## What the banner must make clear | Requirement | Practical Shopify question | |---|---| | Choice | Can shoppers accept, reject, or manage categories clearly? | | Specificity | Are analytics, marketing, functional, and essential uses separated? | | Proof | Can the store show what consent state existed when an event was routed? | | Respect | Do Meta, GA4, TikTok, and other destinations receive only eligible events? | | Updates | Can a shopper change consent later? | ## Why consent and tracking belong together A banner that changes only the UI is not enough. If the storefront still sends the same marketing events after a rejection, the system is not respecting consent. If the pipeline drops all events before storing enough context, the merchant may lose the ability to audit what happened. Eventabee's model is to capture events, keep consent state with the event, and gate destination fanout according to the visitor's region and choices. ## Implementation checklist 1. Define consent categories. 2. Choose regional behavior for EU/UK, US state privacy regions, and the rest of world. 3. Make reject and manage paths as clear as accept. 4. Connect banner choices to Shopify consent state. 5. Route destinations according to consent. 6. Keep receipts or audit evidence for review. 7. Test with VPN/region simulation and browser storage reset. ## Where this fits This is the merchant-facing consent banner pillar. Use [Shopify Customer Privacy API](/blog/shopify-customer-privacy-api-guide) for developer integration details and [Your consent rate is now a growth metric](/blog/consent-is-a-growth-problem) for the growth/attribution framing. ## Key takeaways - This is the canonical merchant-facing consent banner pillar. - Keep Customer Privacy API details on the developer/API spoke. - Keep consent-rate growth framing on `consent-is-a-growth-problem`. - Avoid absolute legal claims; cite requirements and implementation scope. - Eventabee gates destination fanout by consent state. ## FAQ ### Is a Shopify consent banner enough for GDPR? No. The banner is the visible consent collection layer. The store also needs consent state storage, destination routing, policy language, and operational review. ### Where do developer API details belong? Use the Shopify Customer Privacy API guide for developer-level consent-state integration details. ### Can Eventabee guarantee legal compliance? No software can guarantee legal compliance for every merchant. Eventabee can help implement consent-aware event routing and evidence workflows; merchants should review legal obligations with counsel. --- title: Meta CAPI Shopify Setup: The 2026 Guide (Without GTM, Without Code) url: https://honeybound.co/blog/meta-capi-shopify-setup-guide-2026 date: 2026-04-30 summary: A Meta CAPI setup guide for Shopify merchants who want server-side purchase events without building GTM server infrastructure or custom code. tldr: Use this page for Meta CAPI setup. The broader pixel-loss calculation lives on the event-loss pillar, and GA4/TikTok/other destinations should stay on their own setup pages. tags: meta-capi, shopify-integration, eventabee-pricing, ab-testing --- ## Quick answer Meta CAPI for Shopify should send clean server-side purchase and customer events to Meta, deduplicate them against browser events, and respect consent state. The goal is better signal quality, not a magic ROAS fix. Use this page for Meta-specific setup. Use [Shopify pixel conversion-loss math](/blog/shopify-pixel-conversion-loss-math) for the broader diagnosis. ## Setup checklist | Step | What to verify | |---|---| | Event capture | Shopify purchase and customer events are captured correctly | | Event ID | Browser and server events share IDs for deduplication | | Consent | Marketing events are sent only when eligible | | Customer data | Email/phone/address fields are normalized where allowed | | Destination response | Meta accepts events without avoidable errors | | Diagnostics | Event Match Quality limits are visible and actionable | ## What not to promise Meta CAPI can improve signal quality, but it does not guarantee a specific ROAS lift. The result depends on current event loss, consent mix, match data quality, campaign volume, and Meta's optimization behavior. ## Where this fits This is the Meta CAPI setup guide. Use [Shopify pixel conversion-loss math](/blog/shopify-pixel-conversion-loss-math) for the broader diagnosis and [Better ROAS without more ad spend](/blog/better-roas-server-side-tracking-shopify) for the tactical playbook. ## Key takeaways - This is the Meta CAPI setup guide. - Link broad event-loss diagnosis to the pixel-loss pillar. - Verify event IDs, deduplication, consent, and match-quality fields. - Do not promise universal EMQ improvements. - Keep setup steps separate from ROAS claims. ## FAQ ### How much does Eventabee cost? Eventabee offers plans starting at $49/month for the Pro tier, with no usage-based pricing. The Scale plan costs $599/month. ### Does Eventabee support Meta CAPI? Yes, Eventabee supports direct integration with Meta Conversions API (CAPI), enabling server-side tracking without GTM or custom code. ### Can I track A/B tests with Eventabee? Eventabee automatically detects and tracks variants from popular A/B testing tools like Kameleoon and VWO, enriching events for more granular analysis. --- title: Elevar Pricing Explained: Real Costs at 1K, 10K, and 100K Orders (2026) url: https://honeybound.co/blog/elevar-pricing-explained-real-costs date: 2026-04-30 summary: A plain-English Elevar pricing breakdown for Shopify teams comparing order-metered analytics costs with Eventabee flat pricing. Includes assumptions, caveats, and when price should not be the only switching factor. tldr: Elevar pricing is usually evaluated around order volume and feature tier. Eventabee uses flat plan pricing, so the bill does not rise just because order volume or event volume rises. Use this page for the full pricing explanation, then use the calculator companion for scenario math. tags: elevar-pricing, eventabee-flat-rate, server-side-tracking, shopify-analytics --- ## Quick answer Use this page to understand Elevar pricing mechanics. Use the [Elevar calculator](/blog/elevar-bill-calculator) when you want scenario math, and use [Elevar vs. Eventabee](/blog/elevar-vs-eventabee-comparison) when you want a vendor-fit comparison. The main pricing question for Shopify merchants is whether analytics cost should move with order volume. If a tool charges by order tier, a strong month can also become a more expensive tracking month. Eventabee uses flat public plan pricing, so the tracking bill is tied to the workflow tier rather than the number of orders or events. ## Pricing model comparison | Question | Elevar pricing question | Eventabee pricing question | |---|---|---| | What drives cost? | Order volume, tier, contract terms | Plan tier | | What happens during a spike? | Recheck the tier and overage terms | Plan price stays the same | | What should finance model? | Base plan plus volume scenarios | Monthly or annual plan price | | What can change the decision? | Existing implementation, reports, agency process | Destination count, retention, support needs | ## How to compare the two Do not compare a single subscription number in isolation. Build a small table with your actual store assumptions: 1. Current monthly orders. 2. Peak monthly orders. 3. Current Elevar tier or quote. 4. Required destinations. 5. Consent and privacy workflow needs. 6. Migration and QA effort. 7. The Eventabee tier that actually matches the job. Then annualize both sides. If you use annual pricing, say so. If you use a vendor quote, keep the quote date with the calculation. ## When the price difference matters A flat model matters most when the store has seasonal spikes, product drops, rapid growth, or paid-media campaigns that can move order volume quickly. In those cases, per-order pricing can make analytics feel like another tax on growth. It matters less when a team is deeply tied to a specific workflow, agency process, or report. A cheaper subscription does not automatically make a migration worth it. ## Where this fits This is the canonical Elevar pricing explainer. Use the [Elevar calculator](/blog/elevar-bill-calculator) for scenario math and the [Elevar vs. Eventabee comparison](/blog/elevar-vs-eventabee-comparison) for vendor-fit decisions. ## Key takeaways - This is the canonical Elevar pricing explainer; keep calculator math on `elevar-bill-calculator`. - State pricing assumptions and date checked before making savings claims. - Use "in this scenario" language instead of universal savings promises. - Link vendor comparison questions to `elevar-vs-eventabee-comparison`. - Recheck Eventabee public pricing: Pro $49/mo or $39/mo annually; Business $199/mo or $159/mo annually. ## FAQ ### What is this page for? This is the canonical Honeybound page for explaining Elevar pricing structure, order-volume planning, and how to compare it with Eventabee flat pricing. ### Where should I calculate a specific order-volume scenario? Use the Elevar pricing calculator companion page for scenario math, then come back here for caveats and pricing-model context. ### Should I switch based only on price? No. Price matters, but migration work, required destinations, reporting needs, consent workflows, and team habits should also be part of the decision. --- title: OneTrust DSAR Alternatives for Shopify Stores url: https://honeybound.co/blog/onetrust-dsar-alternatives-for-shopify date: 2026-04-29 summary: A Shopify-focused OneTrust DSAR alternatives page for merchants who need DSAR workflows without adopting an enterprise privacy suite. Includes fit, tradeoffs, and migration caveats. tldr: Eventabee can be a OneTrust alternative for Shopify teams that need practical DSAR workflows tied to commerce data, but OneTrust may still fit enterprise privacy programs with broader governance needs. tags: one-trust, dsar-compliance, shopify-pricing, eventabee --- ## Quick answer OneTrust may be the right tool for a company that needs a broad enterprise privacy suite. Eventabee is narrower: it is built for Shopify teams that need consent-aware event routing and practical DSAR workflows tied to commerce data. That difference matters. A smaller Shopify brand may not need the same governance suite as a multinational privacy team, but it still needs a defensible request workflow. ## Fit comparison | Need | OneTrust may fit | Eventabee may fit | |---|---|---| | Enterprise privacy governance | Yes | No, narrower scope | | Shopify event and consent data | Possible with setup | Native focus | | Large legal/privacy team | Often | Less common | | Fast merchant workflow | Depends on implementation | Designed for Shopify operations | | Broad vendor ecosystem | Strong | Focused | ## When not to replace OneTrust Do not replace OneTrust if the business depends on enterprise-wide privacy assessments, vendor risk workflows, or legal processes outside Shopify. Eventabee is not trying to be a general privacy operating system. ## When a Shopify-specific alternative is enough A merchant may only need request intake, identity matching, event-data export, consent evidence, and audit history for Shopify-related systems. In that case, a focused workflow can be easier to operate than a broad suite. ## Where this fits This is the OneTrust vendor-alternative page. Use [CCPA DSAR automation for Shopify](/blog/ccpa-dsar-automation-for-shopify) for the workflow explanation. ## Key takeaways - This is the OneTrust vendor-alternative page. - Keep DSAR workflow education on the DSAR automation guide. - Compare Shopify fit, governance scope, and implementation burden. - Avoid framing enterprise tooling as universally wrong. - State where Eventabee is narrower and more Shopify-specific. ## FAQ ### How much does Eventabee cost? Eventabee's pricing starts at $0 for the Free tier, $49/month for Pro, $199/month for Business, and $599/month for Scale. ### What DSAR features does Eventabee offer? The Business tier includes basic DSAR support with manual review, while the Scale tier offers auto-response based on confidence levels. ### Is Eventabee GDPR compliant? Yes, Eventabee ensures GDPR compliance through consent receipts and tamper-evident manifests retained for 365 days. --- title: Custom pixels without the SSRF footgun url: https://honeybound.co/blog/custom-pixels-without-the-ssrf-footgun date: 2026-04-29 summary: Custom pixel destinations can create SSRF risk. Learn the validation layer Shopify apps need before merchants define webhook endpoints safely. tldr: Merchant-defined webhook destinations are powerful but risky. Custom pixel systems need strict endpoint validation to prevent SSRF and unsafe network access. tags: security, ssrf, shopify --- A merchant adds a custom destination to your app. The URL field accepts any string. They paste `http://169.254.169.254/latest/meta-data/iam/security-credentials/`. Your worker dutifully POSTs to it, gets back AWS IAM credentials, and forwards them to a Slack webhook the same merchant configured five minutes ago. Game over — for you, not them. ## The naive version Most "custom webhook" features start here: a text field for the URL, a text field for the auth header, drop both into `http.Post(...)`. It works in the demo. It ships Friday. It wakes someone up on Monday. Every field a user can type into is an attack surface. A URL field is a remote-code-reach-ability field. ## What an attacker can reach Without validation, the full blast radius: - **Cloud metadata endpoints.** AWS `169.254.169.254`, GCP `metadata.google.internal`, Azure equivalents. These return IAM credentials to anything that can make a TCP connection from inside the VM. - **Internal services on the same Docker network.** `http://postgres:5432`, `http://redis:6379`, anything resolvable by compose service name. - **Localhost.** Your admin endpoints, debug routes, profilers, anything bound to 127.0.0.1. - **Private RFC1918 ranges.** `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`. Whatever's on your private network. - **IPv6 link-local and unique-local.** `fe80::/10`, `fc00::/7`. Easy to forget if your denylist only covers IPv4. - **DNS rebinding.** The URL resolves to a public IP on the first lookup, an internal IP on the second. Validation that only checks once gets bypassed by the actual request. ## What the validation actually has to do Layered, in order: 1. **Resolve the hostname before the HTTP request.** Reject if any resolved IP matches a denylist — private ranges, loopback, link-local, multicast, plus the cloud metadata IPs explicitly. Check both A and AAAA records. 2. **Bind the HTTP client to the resolved IP, not the hostname.** Dial the IP you validated, pass the original hostname in the `Host` header and SNI. The OS cannot re-resolve mid-request. DNS rebinding closed. 3. **Disallow redirects, or re-validate every redirect target.** A 302 back to `169.254.169.254` should not bypass step 1. 4. **Cap response body size.** A malicious endpoint can stream gigabytes just to tie up your worker and egress budget. 5. **Aggressive timeouts.** 5s connect, 15s total is a reasonable starting point. Custom destinations aren't latency-sensitive. 6. **Restrict schemes to `http` and `https`.** No `file://`, no `gopher://`, no `ftp://`. Most libraries default to everything. ## The eventabee implementation The SSRF guard lives once, in the connector layer, shared between the custom-pixel connector and the generic webhook connector. One source of truth, one place to audit, one place to add the next IP range we didn't think of yet. The field-mapper pattern matters here too. Merchants map event fields to destination fields through dropdowns, not a template DSL. There is no arbitrary template execution, no shell expansion, no "interesting" string interpolation. The Business-tier raw JSON template is sandboxed to event-derived field substitution — no code, no functions, no escapes. Validation runs at config save *and* at every send. If DNS resolves differently between Tuesday and Wednesday, the send-time check catches it. ## What you still can't prevent Merchants pointing the destination at themselves and racking up egress bandwidth on your dime. Per-merchant rate limits and a circuit breaker on consecutive 5xx are not optional. Not glamorous. Required. --- If your app lets users define an outbound HTTP destination and you didn't write SSRF validation in the first sprint, assume it's exploitable. Then go check. We built this into [eventabee](/work/eventabee) before the feature shipped — not because it was hard, but because adding it after a merchant pastes the metadata URL is the wrong time to learn. ## Key takeaways - Letting merchants submit arbitrary URLs can expose internal networks or metadata endpoints. - Validation must block private IPs, redirects, unsafe schemes, and suspicious DNS behavior. - A secure custom pixel feature treats destination handling as infrastructure security, not just UI. ## FAQ ### What is the SSRF risk in custom pixels? If a merchant can submit any URL, an attacker may try to make your servers call internal services, private IPs, or cloud metadata endpoints. ### How do you prevent SSRF in webhook destinations? Validate schemes, resolve and block private addresses, re-check redirects, enforce allowlists where possible, and keep network egress constrained. ### Are custom pixel destinations safe for Shopify apps? They can be safe if the app treats destination validation and delivery isolation as core security requirements from the start. --- title: Optimizely Web Experiments on Shopify: Server-Side Attribution Setup url: https://honeybound.co/blog/optimizely-shopify-server-side-attribution date: 2026-04-28 summary: Set up server-side Optimizely attribution on Shopify with Eventabee so experiment IDs enrich conversion events across analytics platforms accurately. tldr: Eventabee Business automates the detection of Optimizely `decide` events, enriching them with experiment IDs and sending this enriched data to analytics tools like Meta CAPI and GA4 for reliable attribution. tags: server-side-tracking, optimizely-integration, shopify-analytics, eventabee-pricing --- Optimizely Web Experiments on Shopify: Server-Side Attribution Setup Running Optimizely experiments on your Shopify store is an effective way to test different versions of pages or features to see which performs better. However, attributing the results back to your analytics and ad platforms can be tricky without a robust server-side tracking solution. Eventabee Business simplifies this process by automatically detecting Optimizely `decide` events, enriching them with experiment and variation IDs, and sending that data to Meta CAPI, GA4, Segment, and more. ## Why Server-Side Attribution Matters for Shopify + Optimizely When you run A/B tests on your Shopify store using Optimizely Web, the results are typically tracked client-side. This means that any conversion events (like purchases or sign-ups) are attributed to the variant a user sees at the time of interaction. However, this approach can lead to incomplete data due to browser privacy settings and ad-blocking extensions. Server-side tracking with Eventabee ensures that every event is captured accurately, even if it’s blocked by client-side restrictions. ## How Eventabee Detects Optimizely Experiments Eventabee Business auto-detects Optimizely `decide` events on the storefront. These events are emitted when a user is assigned to an experiment variant. Once detected, Eventabee enriches server-side events with the relevant experiment and variation IDs. This enriched data is then sent to your analytics platforms (like Meta CAPI or GA4) and ad tools via our integrations. ### How It Works in Detail 1. **Event Detection**: When a user visits your Shopify store and interacts with an Optimizely experiment, Eventabee detects the `decide` event emitted by Optimizely. 2. **Enrichment Process**: Eventabee enriches subsequent server-side events (like purchases or sign-ups) with the experiment ID (`experiment_id`) and variation ID (`variation_id`). This ensures that every conversion is attributed to the correct variant of your test. 3. **Fanout to Analytics Tools**: Enriched events are then sent to your chosen analytics tools via our integrations, including Meta CAPI, GA4, Segment, and more. ## Setting Up Eventabee for Optimizely Experiments To set up server-side attribution with Eventabee Business, follow these steps: ### Step 1: Install the Eventabee App on Shopify First, you need to install the Eventabee app from the Shopify App Store. This involves logging into your Shopify admin panel and navigating to Apps > Manage Private Apps. ### Step 2: Configure Optimizely Integration in Eventabee Once installed, navigate to the Eventabee dashboard within your Shopify store settings. Go to the Integrations section and enable the Optimizely integration. You will need to provide API keys or credentials from your Optimizely account for this setup. ### Step 3: Enable Experiment Auto-Capture In the Eventabee app settings, ensure that the A/B experiment auto-capture feature is enabled. This allows Eventabee to automatically detect and enrich `decide` events emitted by Optimizely on your storefront. ### Step 4: Connect Your Analytics Tools Next, connect your analytics tools (Meta CAPI, GA4, Segment) via the Eventabee dashboard. Each integration has its own setup process. For example, for Meta CAPI, you will need to provide your Pixel ID and access token. ## Comparison with Competitors Let's compare Eventabee Business with some of our competitors in terms of pricing and features: | Feature/Provider | Eventabee Business | Elevar Growth | Littledata Plus | Analyzify Enterprise | |------------------|--------------------|---------------|-----------------|----------------------| | Pricing (Monthly) | $199 | ~$450 | $990 | ~$620 | | Optimizely Integration | Auto-detect + Enrichment | No direct support | Manual setup required | Limited integration support | | Meta CAPI Support | Yes, with enrichment | Basic support | Requires manual mapping | Partial support | | GA4 Support | Yes, with enrichment | Basic support | Requires manual mapping | Partial support | | Segment Integration | Yes, with enrichment | No direct support | Manual setup required | Limited integration support | ## Additional Considerations ### Consent Management and GDPR Compliance Eventabee ensures that all data is collected in compliance with GDPR and other privacy laws. We automatically detect the user's geographic location using Cloudflare CF-IPCountry and MaxMind GeoLite2 for US states. You can configure consent categories (essential, functional, analytics, marketing) and geo modes (opt_in, opt_out, implied) to meet legal requirements. ### DSAR Capabilities Eventabee Business includes basic DSAR capabilities that allow you to manage data subject access requests based on email or phone number. For more advanced needs, Eventabee Scale offers automated responses with high-confidence tagging for quick release of data. ## Conclusion and Next Steps By using Eventabee Business, you can natively integrate Optimizely Web experiments into your Shopify store's analytics pipeline. This ensures that every conversion is accurately attributed to the correct experiment variant, providing you with reliable insights for future optimizations. > Keep Optimizely for experimentation logic. Install Eventabee Business and variation-tagged conversions start landing in your analytics and ad-platform tools the same day. For more information on setting up other A/B testing tools like Kameleoon or VWO, check out our guides on [how-to-track-kameleoon-experiments-in-shopify]({{ site.baseurl }}/blog/how-to-track-kameleoon-experiments-in-shopify) and [vwo-shopify-setup-guide-2026]({{ site.baseurl }}/blog/vwo-shopify-setup-guide-2026). Additionally, if you're interested in server-side tracking for Meta CAPI or GA4, see our detailed setup guides at [meta-capi-shopify-setup-guide-2026]({{ site.baseurl }}/blog/meta-capi-shopify-setup-guide-2026) and [ga4-server-side-tracking-for-shopify]({{ site.baseurl }}/blog/ga4-server-side-tracking-for-shopify). ## Key takeaways - Eventabee Business auto-detects Optimizely experiments on Shopify. - Enriches server-side events with experiment IDs for accurate tracking. - Integrates seamlessly with Meta CAPI, GA4, Segment, and more. - Pricing is $199/mo, far less than competitors like Elevar Growth (~$450/mo). - Ensures GDPR compliance with automatic geographic consent detection. ## FAQ ### How much does Eventabee Business cost? Eventabee Business costs $199 per month or $159 annually for unlimited destinations, custom pixels, and full audit export. ### Does Eventabee integrate with Optimizely? Yes, Eventabee automatically detects Optimizely `decide` events and enriches them with experiment IDs for accurate tracking in analytics tools. ### Can I use Eventabee for GDPR compliance? Eventabee ensures GDPR compliance by auto-detecting user geographic location and configuring consent categories to meet legal requirements. ### How does Eventabee track Optimizely experiments on Shopify? It auto-detects Optimizely 'decide' events when a user is assigned to a variant. Eventabee then enriches subsequent server-side events like purchases with the specific experiment and variation IDs. ### Why is server-side attribution better for Optimizely tests? Client-side tracking is vulnerable to ad blockers and privacy settings, leading to incomplete data. Server-side tracking ensures every conversion is captured accurately regardless of browser restrictions. --- title: Shopify No-Volume-Cap Analytics: Why Per-Order Pricing Is Broken url: https://honeybound.co/blog/shopify-no-volume-cap-analytics date: 2026-04-27 summary: Per-order analytics pricing makes growth harder to forecast. This page explains the no-volume-cap thesis and links to vendor-specific pricing comparisons for Elevar, Littledata, Stape, and Analyzify. tldr: No-volume-cap analytics means the tracking bill does not rise just because orders, events, or campaigns grow. Treat this as the broad pricing-model thesis; use vendor pages for specific comparisons and calculator math. tags: server-side-tracking, elevar, pricing, consent, flat-pricing, a-b-testing --- Shopify analytics pricing isn't just about dollars; it's about the structural tax on your growth. Per-order or per-event metered models can strangle your business as you scale. This post breaks down why flat-price is the only honest model, using real numbers from Elevar, Littledata, Analyzify, and Stape at 10K orders/month. ## The Problem with Metered Pricing Per-order pricing isn't just inconvenient; it's a structural barrier to growth. When your bill moves in lockstep with every order, you're paying more as you succeed. This model penalizes the very success you’re working towards. Consider Elevar Growth: at 10K orders/month, you'd be looking at around $450/mo (see [Elevar Pricing Explained](/blog/elevar-pricing-explained-real-costs)). Littledata Plus charges even more — $990/mo for their premium tier ([Littledata Pricing Breakdown](/blog/littledata-pricing-breakdown)). ## The Math: What You're Actually Paying Let's do the math. At 10K orders/month, here’s how much you'd pay across different providers: | Provider | Monthly Cost at 10K Orders | |----------------|----------------------------| | Elevar Growth | $450/mo | | Littledata Plus| $990/mo | | Analyzify | ~$600/mo | | Stape | Varies, often underestimated | Stape's pricing is notoriously difficult to predict because it's based on GTM requests — a volume that can easily be under-estimated by 3-5x ([Pricing vs Native Shopify](/blog/stape-pricing-vs-shopify-native)). The exact figures for Analyzify are harder to pin down, but they typically fall around $600/mo at 10K orders ([Analyzify Pricing 2026](/blog/analyzify-pricing-2026)). ## Why Flat-Pricing Is the Future Flat pricing is not just a marketing gimmick; it's an essential component of sustainable growth. With Eventabee, you don't pay more as your orders increase — our Business tier costs $199/mo flat, or lock in at $159/mo annually for 24 months ([Eventabee vs Elevar](/blog/elevar-vs-eventabee-comparison)). This means that even if you double your sales, your bill remains the same. ### The Case Against Metered Pricing Metered pricing is a relic of an era when analytics were expensive to process and store. Today's technology makes this model obsolete: - **Cost Inefficiency**: Per-order pricing can inflate costs by up to 60% compared to flat models, as seen with Elevar Growth ([Elevar Bill Calculator](/blog/elevar-bill-calculator)). - **Predictability**: Flat pricing allows you to budget accurately without worrying about unexpected spikes. - **Scalability**: As your business grows, metered pricing can become a significant burden. With Eventabee, growth means more revenue, not higher costs. ## How Eventabee Stands Out Eventabee’s Business tier offers comprehensive features at a flat rate: 1. **Unlimited Destinations**: Connect to Meta CAPI, Google Ads, GA4, TikTok Events API, Pinterest CAPI, Snapchat CAPI, Klaviyo, PostHog, Segment, and more. 2. **A/B Experiment Auto-Capture**: Automatically track experiments with Kameleoon, VWO, Visually A/B, Optimizely ([How to Track Kameleoon Experiments](/blog/how-to-track-kameleoon-experiments-in-shopify)). 3. **GDPR Compliance**: Manage consent categories and geo-specific modes without breaking the bank. 4. **DSAR Automation**: Handle data subject access requests efficiently with our built-in tools. ### Real-World Example: Meta CAPI Integration Setting up Meta CAPI is straightforward and essential for Facebook Ads tracking ([Meta CAPI Setup Guide](/blog/meta-capi-shopify-setup-guide-2026)). With Eventabee, you can ensure your events are correctly mapped to the Meta Events API without worrying about per-event costs. ## The Elephant in the Room: Competitor Pricing Let's break down what competitors charge: | Provider | Monthly Cost at 10K Orders | |----------------|----------------------------| | Elevar Growth | $450/mo | | Littledata Plus| $990/mo | | Analyzify | ~$600/mo | | Stape | Varies, often underestimated| Enzuzo focuses on consent and DSAR but lacks the comprehensive analytics capabilities Eventabee offers ([Pricing Explained](/blog/enzuzo-pricing-explained)). Onetrust is overkill for most SMBs, offering enterprise features that are unnecessary for Shopify stores. ## Conclusion: The Case for Flat Pricing Flat pricing isn't just about saving money; it's about removing the structural barriers to growth. Metered models penalize your success, while flat pricing ensures you can scale without worrying about unexpected costs. Eventabee’s Business tier is designed to support rapid growth and comprehensive analytics at a fixed price. > Pick Eventabee Business at $199/mo flat, or lock $159/mo annual for 24 months. Your bill does not move when your store doubles. ## Key takeaways - This is the broad no-volume-cap analytics thesis. - Vendor-specific cost claims belong on the matching pricing or comparison page. - Flat pricing is strongest when order volume is seasonal or growing. - Budget predictability is part of analytics quality. - Link back to Eventabee pricing and vendor comparison pages for decisions. ## FAQ ### How does Eventabee compare to Littledata in terms of pricing? Eventabee’s Business tier costs $199/mo or $159/mo annually for 24 months. In contrast, Littledata Plus charges a metered rate that can reach up to $990/mo. ### What are the benefits of flat pricing in analytics? Flat pricing ensures predictable budgeting and supports scalable growth without penalizing increased order volumes or events. ### Does Eventabee support A/B testing integration? Yes, Eventabee’s Business tier includes automatic detection and tracking for experiments with Kameleoon, VWO, Visually A/B, Optimizely, and more. --- title: Elevar Pricing Calculator for Shopify: Flat vs Volume Costs url: https://honeybound.co/blog/elevar-bill-calculator date: 2026-04-25 summary: Use this worksheet to compare Elevar order-volume pricing against Eventabee flat pricing. The Elevar pricing guide explains the model; this page is the calculator companion. tldr: Use this page when you want the math. Enter monthly order volume, compare Elevar Growth or Business against Eventabee Pro or Business, then annualize the difference. For the full pricing breakdown and caveats, read the Elevar pricing explainer. tags: server-side-tracking, elevar-pricing, eventabee, consent-management, dsar-automation --- ## Quick answer Use this page as the calculator companion to the [Elevar pricing explainer](/blog/elevar-pricing-explained-real-costs). The pricing explainer should answer "how does Elevar pricing work?" This page answers a narrower question: "what does my bill look like at this order volume compared with flat Eventabee pricing?" The safest way to use the comparison is simple: 1. Pick your current or projected monthly order volume. 2. Use the Elevar tier and contract terms you actually have. 3. Compare it with the Eventabee tier that matches your required destinations and retention. 4. Annualize both numbers. 5. Treat the result as a planning estimate, not a guaranteed savings claim. Eventabee's public pricing at the time of this refresh: | Eventabee plan | Monthly | Annual-plan effective monthly | Notes | |---|---:|---:|---| | Pro | $49/mo | $39/mo | 3 destinations, performance recovery, live event stream | | Business | $199/mo | $159/mo | Unlimited destinations, EMQ/Event Quality, external-domain support, monthly Impact Report | For full context, read the [Elevar pricing explainer](/blog/elevar-pricing-explained-real-costs) and the [Elevar vs. Eventabee comparison](/blog/elevar-vs-eventabee-comparison). ## Calculator worksheet Use the table below as a worksheet. Replace the Elevar numbers with your actual quote or renewal terms before making a switching decision. | Scenario | Monthly orders | Elevar monthly cost | Eventabee plan | Eventabee monthly cost | Monthly difference | Annualized difference | |---|---:|---:|---|---:|---:|---:| | Current baseline | 10,000 | Enter your cost | Pro or Business | $49 / $199 monthly, or $39 / $159 annual | Calculate | Calculate | | Growth case | 50,000 | Enter your cost | Pro or Business | $49 / $199 monthly, or $39 / $159 annual | Calculate | Calculate | | Peak season | 100,000 | Enter your cost | Pro or Business | $49 / $199 monthly, or $39 / $159 annual | Calculate | Calculate | The key question is not whether one sticker price looks lower. The question is whether your analytics cost moves when order volume, event volume, campaign volume, or seasonal demand moves. ## Formula ```text monthly_difference = elevar_monthly_cost - eventabee_monthly_cost annualized_difference = monthly_difference * 12 ``` If you are comparing annual contracts, use the effective monthly price from the annual plan and disclose that assumption. Example: ```text Elevar monthly cost: $950 Eventabee Business annual-plan effective monthly cost: $159 Monthly difference: $791 Annualized difference: $9,492 ``` That does not mean every merchant saves $9,492. It means a merchant in that scenario, with those exact assumptions, would budget about $9,492 less over a year. ## What to include in the comparison A useful calculation includes more than the software subscription. | Cost area | Why it matters | |---|---| | Base subscription | The recurring platform fee. | | Order or event volume | Metered tools can move with growth, promotions, or seasonality. | | Destination count | A cheaper tier may not include every destination you need. | | Implementation work | Migration time, QA, and destination validation still cost money. | | Consent and DSAR scope | Privacy workflow gaps often become manual work somewhere else. | | Reporting needs | Some teams need dashboards, impact reports, or export workflows. | ## When flat pricing matters most Flat pricing matters most when a Shopify store has uneven or growing order volume. A brand may be steady for most of the year, then spike during a product drop, holiday campaign, influencer campaign, or paid-media push. If analytics pricing follows order volume, the bill can rise during the same month the team is already spending more on acquisition. Eventabee is designed around a different budget model: choose the tier for the workflow you need, then keep event and order volume out of the pricing formula. ## When Elevar may still make sense Do not switch tools just because a spreadsheet says the subscription is cheaper. Elevar may still make sense if your team already depends on a specific workflow, report, agency process, or implementation pattern that is more valuable than the price difference. Use this page to ask better questions before renewal: - Which tier are we actually on? - What happens if order volume doubles for a month? - Are we paying for reporting, server-side destinations, consent workflows, or all three? - Which features do we actually use every week? - What would migration and QA cost? ## Related reading - [Elevar pricing explained: real costs at 1K, 10K, and 100K orders](/blog/elevar-pricing-explained-real-costs) - [Elevar vs. Eventabee: feature, price, and migration comparison](/blog/elevar-vs-eventabee-comparison) - [Shopify no-volume-cap analytics: why per-order pricing is broken](/blog/shopify-no-volume-cap-analytics) ## Key takeaways - This page is the calculator/worksheet companion, not a second Elevar pricing article. - Keep the full pricing explanation on `elevar-pricing-explained-real-costs`. - Use current public pricing and dated assumptions before publishing savings claims. - Eventabee pricing is flat: Pro is $49/mo or $39/mo annually; Business is $199/mo or $159/mo annually. - Savings claims should say "in this scenario" and show exact order-volume assumptions. ## FAQ ### Is this the same as the Elevar pricing explainer? No. The Elevar pricing explainer is the canonical article for how Elevar pricing works. This page is the worksheet for running order-volume scenarios. ### What Eventabee prices should I use in the calculator? Use the current public Eventabee prices: Pro is $49/month or $39/month annually, and Business is $199/month or $159/month annually. Recheck pricing before publishing a dated comparison. ### Can I treat the savings estimate as guaranteed? No. Treat it as a scenario estimate based on the order volume and tier assumptions shown on the page. Vendor pricing, contracts, annual discounts, and feature needs can change the result. --- title: Token Exchange killed the OAuth redirect url: https://honeybound.co/blog/token-exchange-killed-oauth-redirect date: 2026-04-22 summary: Shopify Token Exchange and Managed Installation change OAuth app setup. See what to delete, what to build, and which migration gotchas matter. tldr: Shopify Token Exchange changes the app install flow. Modern embedded apps should remove legacy OAuth redirects and rely on managed installation patterns. tags: shopify, auth, embedded-apps --- There's a tab open in your browser right now that loads `https://your-app.com/auth?shop=...&hmac=...×tamp=...`. If you wrote that route after January 2025, you wrote dead code. The new model — Managed Installation plus Token Exchange — has been the recommended path for embedded Shopify apps for almost a year. Most tutorials still teach the redirect flow because Shopify hasn't taken the old docs down. They should. The migration is shorter than people think, and the result is simpler in every direction. ## What changed Managed Installation moved the install + consent screen *into Shopify itself*. You declare the scopes your app needs in `shopify.app.toml`, push it with `shopify app deploy`, and Shopify handles the install UX. No redirect. No state nonce. No HMAC-on-querystring dance. App Bridge — the JS SDK that runs inside the Admin iframe — mints a session token (a JWT) on every request from the embedded UI. Your backend takes that JWT and exchanges it for an offline access token via the Token Exchange endpoint. The offline token is what you use for every subsequent Shopify API call. End state: no `/auth` route, no `/auth/callback`, no nonces, no install-flow cookies, no post-install redirect logic. Just middleware. ## What you delete - The `/auth` install URL builder - The `/auth/callback` handler - The HMAC verifier on the redirect query string (you still need HMAC on webhooks — don't delete that one) - The cookie-based pre-auth session - The post-install redirect URL builder - The `state` nonce store Most of this lives in one or two files. Deleting it is satisfying. ## What you write instead Middleware. About 80 lines of Go. The shape: 1. Pull the JWT out of the `Authorization: Bearer …` header. 2. Validate the signature against your app secret. 3. Verify the audience and issuer claims — both must match the shop domain making the request. 4. Look up an offline token for that shop in Redis. 5. If miss: call Token Exchange with the JWT as `subject_token`, cache the returned offline token under `{app}:token:{shop_domain}`. 6. Hand the offline token to the request context. That's it. One round-trip per uncached shop, then everything is local. ## Gotchas nobody warns you about **Session tokens expire after 60 seconds.** App Bridge auto-refreshes them on the client. Server-side webhook handlers don't have App Bridge. They still need HMAC verification — do not delete that path. **`invalid_subject_token` is a soft error.** Token Exchange returns it when a shop has uninstalled mid-flight, or when the JWT is past its 60-second window. Treat it as a 401 and let the client retry. Treating it as a 500 will fill your error tracker with noise during normal uninstalls. **The offline token can be revoked out-of-band.** A merchant can uninstall and reinstall in the same minute. Your cache won't know. The right invalidation trigger is "next failed API call returns `invalid_token`" — not the install webhook, which can race. **Local dev still uses the live Shopify issuer.** Even when you're tunneling to localhost, the JWT issuer is the production Shopify domain. Don't hardcode issuer checks against your tunnel URL. ## When NOT to migrate If your app is non-embedded — lives outside the Admin iframe and serves its own dashboard — OAuth redirect is still the right tool. App Bridge isn't there to mint session tokens, so there's nothing to exchange. Our event pipeline app stays on OAuth redirect for exactly this reason. Embedded apps are the ones that benefit. --- Recurrabee and searchabee both run this pattern in production today — [see /work](/work) for what they actually do. The migration took a couple of afternoons each. The auth code that's left is shorter, easier to reason about, and stops being something you have to think about. ## Key takeaways - Managed Installation shifts install authorization away from custom OAuth redirect handling. - Token Exchange gives embedded apps a safer way to obtain app access tokens. - The migration is mostly deleting old redirect assumptions and tightening app-session logic. ## FAQ ### Does Shopify still require OAuth redirects for embedded apps? Modern managed-installation apps can use Token Exchange instead of maintaining a full legacy OAuth redirect flow. ### What should be removed during a Token Exchange migration? Remove old redirect handlers, callback-state assumptions, and install-path logic that conflicts with Shopify managed installation. ### What is the biggest Token Exchange migration risk? The main risk is keeping mixed legacy and modern flows alive, which can create broken installs or confusing session behavior. --- title: Your consent rate is now a growth metric url: https://honeybound.co/blog/consent-is-a-growth-problem date: 2026-04-18 summary: Consent rate affects attribution quality, but it should not be treated as a trick to bypass user choice. This opinion piece explains why banner UX and event routing belong in the same growth system. tldr: Consent rate is a growth metric because rejected or unclear consent changes what ad platforms and analytics tools can see. The fix is not manipulative banner design; it is clear consent UX plus an event pipeline that respects the resulting state. tags: privacy, attribution, consent --- A visitor lands on your store, clicks **Reject** on the cookie banner, browses for six minutes, and buys a $180 bundle. Meta never hears about it. Neither does Google. Neither does Klaviyo. The conversion happened — your ad accounts just don't know. Multiply that by a 30% reject rate (low, for the EU) and a quarter of paid-media spend, and the math gets ugly fast. ## This used to be a privacy problem. Now it's an attribution problem. In the old browser-pixel world, a consent rejection meant your analytics dashboard got a little fuzzier. Annoying, not existential. In a world where Meta CAPI, Google Enhanced Conversions, and TikTok Events API *are* the optimization signal, a rejected visitor is a hole in the dataset the ad platform uses to find more buyers. Reject rates of 25–40% in regulated regions don't fuzz your dashboards anymore — they tell Meta you have 30% fewer conversions than you do, and Meta optimizes accordingly. ROAS drifts down for a quarter and nobody can point to the deploy that caused it. ## The split-vendor trap Most stores run two unrelated systems for this. A banner vendor — OneTrust, Cookiebot, Iubenda — that shows the cookie UI and writes a consent cookie. And a separate event pipeline — a CDP, a tag manager, a server-side connector — that actually delivers events. The two never share state. So when a visitor returns a week later and grants consent (which happens more than you'd think), the pipeline has no idea that events from the rejected window now have permission to fire. They were discarded at the door. They're not coming back. That's a structural defect, not a configuration one. You can't fix it by swapping banner vendors. ## What we built [eventabee](/work/eventabee) owns both halves. The geo-aware consent banner auto-applies the right mode by region — `opt_in` for the EU and UK, `opt_out` for the 19 US states with active privacy laws, `implied` everywhere else — with per-region layout enforcement so you can't accidentally ship a GDPR-illegal button arrangement. The pipeline does something most don't: it **always stores the event**, even when the visitor hasn't consented. Consent is checked at *fanout*, not at ingest. Non-consented destinations are skipped for that event; the event itself sits in the store, untouched. When the visitor later upgrades consent — clicks **Accept All** on a return visit, opts in via the preferences re-entry button — eventabee replays up to **30 days** of stored events to the newly-permitted destinations, tagged `backfilled: true` so attribution reports stay clean. Consent upgrades become a recovery vector instead of a loss event. Same pipeline that recovers the [browser pixel events you were already losing](/blog/event-loss-is-invisible), now recovering the consent-rejected ones too. Two leaks, one system, one fix. ## Key takeaways - This is the opinion/framing spoke for consent and growth. - Link implementation details to the GDPR banner and Customer Privacy API guides. - Do not frame consent optimization as bypassing user choice. - Measure reject rates, unknown states, and downstream event eligibility. - Banner UX and event routing should be owned together. ## FAQ ### How does a high reject rate on cookie banners affect ad optimization? A high reject rate means fewer conversions are attributed to ads, leading platforms like Meta to optimize as if there were fewer actual buyers, which can cause ROAS (Return on Ad Spend) to decline. ### What is the structural defect in most stores' consent systems? Most stores use separate vendors for showing cookie banners and delivering events. This means they don't share state, so when a visitor grants consent later, previously discarded events due to rejection cannot be resent or recovered. ### How does eventabee handle consent and event storage differently? Eventabee always stores events regardless of initial consent status and checks consent at the fanout stage rather than during ingest. This allows it to replay up to 30 days of stored events when a visitor grants additional consent later. ### What are the different modes that eventabee's geo-aware consent banner applies automatically? The banner auto-applies `opt_in` for EU and UK, `opt_out` for US states with privacy laws, and `implied` elsewhere, adjusting layouts to comply with regional regulations. --- title: Event loss is invisible — until your ad spend tells on it url: https://honeybound.co/blog/event-loss-is-invisible date: 2026-04-08 summary: A short opinion piece on why Shopify event loss is hard to notice until ad platforms optimize against incomplete conversion data. Links to the pixel-loss math pillar. tldr: Event loss usually does not throw an error. It shows up later as weaker attribution, poorer optimization, and mismatched reporting. Use the pixel-loss math pillar for diagnosis and calculation. tags: tracking, events, ads --- A browser pixel that misses 15% of purchase events doesn't throw an error. The merchant's dashboard doesn't blink. The only signal is a slow, steady drift: your Meta CAPI ROAS declines by 10–20% over a quarter and nobody can point to a deploy that caused it. ## Why events go missing Safari ITP caps first-party cookie lifetime. Brave strips trackers entirely. Firefox's enhanced tracking protection blocks the Meta pixel on many page types. Content blockers are installed on an estimated 30% of ecommerce traffic. Every one of these events is a conversion your ad platform thinks didn't happen — so it optimizes against you. ## Server-side is the answer, but it needs to be reliable [eventabee](/work/eventabee) ships events server-side from the Shopify Pixel extension through a per-shop pipeline with: - Retry on 5xx with exponential backoff + DLQ - Deduplication on `event_id` across the browser + server paths - Per-destination transformation (CAPI, TikTok Events API, GA4 Measurement Protocol, Klaviyo, Pinterest, Snap) - Full replay from the event store when a destination credential rotates The result: the events the browser loses still arrive at the destination. Merchants who switch typically recover 10–25% of "missing" purchases within a week. ## Key takeaways - This is the short opinion/framing spoke for event loss. - Keep diagnostic math on `shopify-pixel-conversion-loss-math`. - Event loss should be measured, not guessed. - Missing events affect optimization loops. - Link readers to tactical recovery guides. ## FAQ ### What is event loss? Event loss is the gap between customer actions that happen on your store and conversion events that actually reach analytics or ad platforms. ### Why is event loss invisible? Most dashboards only show received events, so they do not clearly reveal the conversions that were blocked, dropped, or never sent. ### How does Eventabee reduce event loss? Eventabee sends first-party server-side events with stronger identifiers and consent-aware routing, improving the conversion signal sent to ad platforms. --- title: Why Shopify's 50-product filter limit breaks on large catalogs url: https://honeybound.co/blog/shopify-50-product-filter-limit date: 2026-04-01 summary: Shopify's native collection filters can miss products on large catalogs when shoppers filter from a limited result set. This guide explains the failure mode and when Searchabee is the better architecture. tldr: Shopify filters are fine for small catalogs, but large catalogs need search/filtering that evaluates the whole matching set, not only the products currently visible on a collection page. If shoppers cannot narrow by size, fit, material, use case, or availability across the full catalog, search becomes a merchandising problem. tags: shopify, search, performance --- ## Quick answer Shopify's native filters are usually enough for small catalogs. They start to break down when a store has enough products, variants, tags, and attributes that shoppers need to filter across the whole catalog, not only the small slice of products currently visible on a collection page. That is the Searchabee use case: make filtering and search evaluate the real product set, then give merchants control over the product attributes, synonyms, boosts, and merchandising rules that decide what shoppers see. ## What shoppers notice The failure usually looks like a UX problem, but the root cause is product discovery. | Shopper action | Broken experience | Business cost | |---|---|---| | Filter by size or fit | Matching products exist but do not appear | Shopper assumes the store is out of stock | | Filter by material or use case | The result set is too small or noisy | High-intent products stay buried | | Search a synonym | The catalog uses different product language | Search looks worse than the inventory really is | | Browse a large collection | Filters feel arbitrary or incomplete | Merchandising loses control of the path to purchase | The merchant does not see an error. The shopper just leaves. ## Why native collection filtering is not the whole answer Native filtering works best when the collection is small, the attributes are simple, and the theme only needs to narrow a manageable set of products. Large catalogs are different. They need filtering that understands the catalog as data: product fields, variants, tags, metafields, synonyms, availability, and merchant priorities. A filter that only works on a limited visible set can hide valid products. A shopper may choose "blue," "wide," "waterproof," or "vegan" and get a thin result set even though the catalog has matching inventory elsewhere. ## When this becomes a Searchabee problem A store should consider Searchabee when one or more of these are true: - Collections regularly hold hundreds or thousands of products. - Shoppers filter by variant-level attributes such as size, color, fit, compatibility, or material. - Search terms and product language do not match cleanly. - Merchants need synonyms, boosts, exclusions, or pinned results. - Zero-result searches happen for products the store actually sells. - Native collection filters make the catalog look smaller than it is. ## What better architecture looks like Large-catalog filtering should evaluate the full relevant product set first, then render shopper-friendly controls. The index should know the attributes shoppers care about and the merchandising rules the merchant wants to enforce. | Need | Native-filter symptom | Search-first approach | |---|---|---| | Full-catalog matching | Results depend too much on the current collection slice | Query the indexed catalog before presenting filters | | Synonyms | "sofa" and "couch" behave differently | Normalize shopper language into product language | | Variant awareness | Size/color availability feels inconsistent | Index attributes at the level shoppers use them | | Merchandising | Best products do not surface reliably | Boost, pin, or bury products intentionally | | Analytics | Merchants cannot see failed discovery paths | Track searches, zero-results terms, and filter usage | ## Practical merchant checklist Before adding another collection template or tag workaround, check the actual discovery problem: 1. List the top 20 search terms and filter combinations. 2. Confirm whether matching products exist for each one. 3. Compare what native filtering shows against what the catalog actually contains. 4. Identify synonyms shoppers use that product data does not use. 5. Decide which products should be boosted, pinned, or hidden for high-intent queries. 6. Track zero-result and low-result searches weekly. If the problem is data coverage and merchandising control, theme tweaks will only hide the symptom. ## Where this fits This is the canonical Searchabee article for Shopify large-catalog filtering. Future Searchabee posts should link back here when they discuss synonyms, collection filters, search analytics, merchandising rules, or zero-result recovery. Related pages: - [Searchabee work page](/work/searchabee) - [Honeybound services](/services) - [Shopify no-volume-cap analytics](/blog/shopify-no-volume-cap-analytics) ## Key takeaways - Treat this as the canonical Searchabee page for large-catalog Shopify filtering. - The merchant problem is not only search UX; it is missed product discovery. - Large catalogs need filters that evaluate the relevant product set, not a thin visible slice. - Searchabee should be positioned around accurate filtering, better merchandising, and fewer dead-end collection pages. - Link new Searchabee posts back here instead of creating another broad filter-limit article. ## FAQ ### Why do Shopify filters break down on large catalogs? Large catalogs often have more products, variants, tags, metafields, and merchandising rules than native collection filtering can expose cleanly from a limited visible result set. ### What is the shopper-visible symptom? A shopper applies a filter and sees too few results, no results, or the wrong product mix even though matching products exist elsewhere in the catalog. ### When should a merchant use Searchabee? Use Searchabee when discovery depends on full-catalog search, precise filters, synonyms, product attributes, or merchandising rules that native collection filtering cannot represent reliably. --- title: Install recurrabee url: https://honeybound.co/work/recurrabee/guides/install app: recurrabee category: getting-started summary: Install from Shopify, grant scopes, and open the merchant console. --- recurrabee runs on top of Shopify's native Subscription Contracts API. Before installing, confirm your store has access to the subscription APIs — typically that means Shopify Plus or an approved plan. ## 1. Confirm subscription eligibility From Shopify Admin, go to Settings → Apps and sales channels → Develop apps (or check with your Shopify account rep). If Subscription Contracts aren't available yet, [contact us](/contact) and we'll help you request access. ## 2. Install During beta we send a direct install link. Click it from a browser signed in to the target store. Shopify takes you through install consent. ## 3. Grant scopes recurrabee requests scopes to read and write subscription contracts, customers, orders, and selling plans. The subscription API scopes are protected — Shopify prompts the store owner to approve them specifically. ## 4. Open the console After install you'll land on the recurrabee console, embedded inside Shopify Admin (recurrabee uses Managed Installation + Token Exchange, the 2025 Shopify auth pattern). The home view shows contract counts and any contracts currently in past-due state. ## Next steps - [Install the Checkout UI extension](/work/recurrabee/guides/checkout-ui-extension) - [Create your first selling plan](/work/recurrabee/guides/creating-selling-plans) - [Configure dunning](/work/recurrabee/guides/dunning-configuration) --- title: Install the Checkout UI extension url: https://honeybound.co/work/recurrabee/guides/checkout-ui-extension app: recurrabee category: getting-started summary: Add the subscriber self-serve block to your checkout and customer account. --- The Checkout UI extension gives subscribers a self-serve panel in their customer account where they can pause, skip, swap, or cancel active subscriptions — no support ticket required. ## 1. Open the checkout and accounts editor Shopify Admin → **Settings → Checkout → Customize** (or for the customer account surface: **Settings → Customer accounts → Customize**). ## 2. Add the recurrabee block In the Customer account surface, add the **Subscriptions** block from the recurrabee app. Drag it to the position you want on the account home page (usually below the order history). ## 3. Configure visibility By default, subscribers see all their active contracts. Options: - **Paused contracts:** show / hide - **Cancelled contracts:** show / hide (archive view) - **Actions allowed:** any subset of pause, skip, swap, cancel Merchants often hide cancel (driving those to a retention flow via support) while keeping pause and skip self-serve. Set per your retention strategy. ## 4. Save and publish Click Save. Changes are live immediately. ## What subscribers see A clean list of their active contracts with: product, cadence, next billing date, and the actions you've permitted. Each action confirms and updates the contract via the recurrabee state machine — so the transition is logged, replayable, and observable in the merchant console. ## Theming The block inherits your theme's typography and color variables. For stricter brand control, override per component in the editor's Theme settings. ## Next - [Create your first selling plan](/work/recurrabee/guides/creating-selling-plans) - [Configure dunning](/work/recurrabee/guides/dunning-configuration) --- title: Create a selling plan url: https://honeybound.co/work/recurrabee/guides/creating-selling-plans app: recurrabee category: getting-started summary: Define subscription cadences and discounts and attach them to products. --- A selling plan defines *how* a product can be purchased on subscription: cadence, discount, trial, anchor behavior. Selling plans live in Shopify; recurrabee's console is the merchant-facing editor. ## 1. Open the selling plans view recurrabee console → **Plans**. ## 2. Create a selling plan group A **group** is a bundle of related plans (e.g., "Monthly / Bi-monthly / Quarterly" for a supplement). Create the group with a name and description. ## 3. Add plans Within the group, add individual plans: - **Cadence:** `P1M` (monthly), `P14D` (every 2 weeks), etc. recurrabee validates the ISO-8601 duration format. - **Discount:** optional; percentage, fixed amount, or fixed price per delivery. - **Trial:** optional; free days before the first billing. - **Anchor:** optional; snap deliveries to a day-of-month or day-of-week. ## 4. Attach to products Each plan group is attached to one or more products. In the **Products** tab of the group, select the products (and optionally specific variants) that should be eligible. Attached products immediately show a "Subscribe and save" option on the storefront (pending your theme's support for selling plans — most Shopify 2.0 themes already render it). ## 5. Test From an anonymous browser, visit a product page, pick the subscription option, and check out. Confirm: - The order is tagged as a subscription. - A contract is visible in recurrabee console within seconds. - The next billing date matches the plan's cadence. ## Common patterns - **Save X% with subscription.** A single plan with a percentage discount. Low-friction. - **Build a box.** A plan with no discount but a curated bundle — sells on convenience. - **Replenishment with trial.** 14-day free trial, then monthly. Useful for CPG. ## Edge cases - **Free shipping on subscriptions.** Configured via Shopify's standard shipping rules, not in the plan itself. - **Mid-cycle swaps.** Handled by the recurrabee state machine — see the [managing contracts guide](/work/recurrabee/guides/managing-contracts). --- title: Configure dunning url: https://honeybound.co/work/recurrabee/guides/dunning-configuration app: recurrabee category: getting-started summary: Retry policy, branded emails, and the past-due state. --- Dunning is how you recover failed payments. Done well, it saves 20–40% of subscription revenue that a naive "charge once, cancel on fail" flow throws away. ## 1. Open dunning settings recurrabee console → **Settings → Dunning**. ## 2. Retry schedule Default schedule (tunable per merchant): ``` Attempt 1: on failure Attempt 2: +1 day Attempt 3: +3 days Attempt 4: +7 days Terminal: +14 days → cancel ``` Each attempt is a real Shopify charge via the subscription contract. The contract enters **past-due** state on the first failure and remains there until either a retry succeeds (→ active) or the terminal attempt exhausts (→ cancelled). ## 3. Branded emails For each retry step you can enable an email to the subscriber: - **Soft retry (attempt 2–3):** "Your card on file was declined. We'll try again in a couple days. Update your payment method to avoid interruption." - **Hard retry (attempt 4):** "Final retry coming up. Update now to avoid cancellation." - **Terminal:** "Your subscription was cancelled after multiple failed attempts." Emails use ZeptoMail (the same transactional provider the rest of the stack uses). Copy is merchant-editable; the default copy is reviewed for tone (firm but not hostile). ## 4. Include update payment link Every dunning email includes a magic link to Shopify's customer account → payment methods page, where the subscriber can update their card in one click. This is what actually moves the needle on recovery. ## 5. Past-due visibility recurrabee's console has a **Past-due** view that lists every contract currently in dunning, ordered by next retry date. You can manually trigger a retry now, cancel early, or mark the contract as "don't retry" (for customers you've already reached out to via support). ## Why a state machine? Dunning crosses many entities — a billing attempt, a notification, a state transition, a customer. Keeping it in a state machine (rather than a pile of booleans on the contract row) means every transition is logged, replayable, and testable. ## Next - [Managing contracts](/work/recurrabee/guides/managing-contracts) - [Shopify Flow integration](/work/recurrabee/guides/shopify-flow-integration) --- title: Set up the customer portal url: https://honeybound.co/work/recurrabee/guides/customer-portal-setup app: recurrabee category: getting-started summary: The subscriber-facing page — enable the Customer Account block. --- recurrabee's "portal" is not a separate website — it lives inside Shopify's Customer Accounts surface, which is where your subscribers already go to manage their orders. ## 1. Confirm you're on New Customer Accounts Shopify Admin → **Settings → Customer accounts**. You want **New customer accounts** (not Classic). All new stores default to New; older stores may still be on Classic. If you're on Classic: Shopify is sunsetting it. Migrate to New first — it's a one-click upgrade for most stores, and New is where Customer Account UI extensions (like recurrabee's subscriber block) run. ## 2. Enable the recurrabee block Covered in the [Checkout UI extension guide](/work/recurrabee/guides/checkout-ui-extension). Same process — the customer account editor is where you drop the block in. ## 3. Customize the subscriber landing Subscribers land on the account home page when they click "Manage subscriptions" from dunning emails. Make sure the subscription block is above the fold and clearly labeled. ## 4. Authenticate Shopify's customer account login (magic link + email) handles auth. recurrabee piggybacks — there's no second password. ## 5. What subscribers can do Per your [action configuration](/work/recurrabee/guides/checkout-ui-extension): - View active, paused, and cancelled contracts - Pause and resume - Skip the next billing cycle - Swap products (if enabled) - Cancel (with reason selection if enabled) - Update payment method (deep-link to Shopify's payment page) - Update shipping address ## Branding Customer Account UI extensions inherit your theme's colors and typography by default. Override per component in the editor. ## Why not build a standalone portal? Because subscribers already know where to go for their orders. Putting subscription management in the same place reduces support volume and cuts confusion. It also means we don't reinvent auth. --- title: Manage subscription contracts url: https://honeybound.co/work/recurrabee/guides/managing-contracts app: recurrabee category: operations summary: Pauses, swaps, skips, and cancels — done through the state machine. --- Every subscription contract in recurrabee is a state machine instance. The allowed transitions are: ``` active → paused active → cancelled active → past-due (on billing failure) paused → active past-due → active (on successful retry) past-due → cancelled (on terminal failure or manual cancel) ``` Every transition is logged with timestamp, actor, and reason. You can see the full history from the contract's detail page in the console. ## Pause Pauses halt billing and shipment without cancelling. Subscribers keep their plan, discount, and cadence. - **From the console:** any active contract → **Pause**. Choose an optional resume date. - **From the customer account block:** subscriber-initiated, same effect. When a pause resume date arrives, the contract returns to active and resumes the cadence from that date. ## Skip Skip advances the next billing date by one cycle without changing state. Useful when a subscriber is travelling or has too much product. ## Swap Swap changes the product/variant on an active contract mid-cycle. recurrabee updates the Shopify Subscription Contract and preserves the billing anchor. - **Simple swap:** same price point, same cadence. No proration. - **Tier swap:** different price. Proration behavior is configurable (off by default — simpler, fewer edge cases). ## Cancel Cancels the contract. Shopify's cancel reason codes are surfaced so you can build cancel flows with structured data. - From the console: **Cancel contract**. Choose a reason code, optionally add a note. - From the customer account block: if self-serve cancel is enabled, subscribers pick from a merchant-defined list of reasons before confirming. ## Observing state Every state transition emits: - An entry in the contract's activity log (console). - A Shopify Flow trigger (if you've opted in — see [Flow integration](/work/recurrabee/guides/shopify-flow-integration)). - A webhook to any URL you've configured (**Settings → Webhooks**). - An email to the subscriber (if the merchant opted in for that transition — off by default for pause/skip, on for cancel). ## Bulk operations For ops scenarios (migrating subscribers, emergency pauses), **Contracts → Bulk actions** supports CSV upload of contract IDs with the desired action. --- title: Shopify Flow integration url: https://honeybound.co/work/recurrabee/guides/shopify-flow-integration app: recurrabee category: operations summary: Trigger Flow workflows on every subscription state transition. --- recurrabee emits Shopify Flow triggers on every state transition. This lets merchants automate downstream actions — tagging customers, firing Klaviyo flows, alerting in Slack, adjusting fulfillment — without writing code. ## Available triggers - `Subscription activated` — contract enters active state - `Subscription paused` - `Subscription resumed` - `Subscription skipped` - `Subscription past-due` — billing attempt failed - `Subscription recovered` — past-due → active after successful retry - `Subscription cancelled` — with reason code in the payload - `Subscription swapped` — product/variant changed Each trigger carries the contract, the customer, and relevant metadata. ## Setting up a Flow workflow 1. Shopify Admin → **Apps → Flow → Create workflow**. 2. Start trigger: pick one of the recurrabee triggers from the list. 3. Add conditions and actions as you would for any Flow workflow. ## Example workflows ### Tag customers in dunning - Trigger: `Subscription past-due` - Action: Add customer tag `in-dunning` - Paired workflow: Trigger `Subscription recovered` → Remove tag `in-dunning` Useful for segmenting in Klaviyo or for suppressing promotional emails to customers who are already in a payment issue. ### Slack alert on cancellations - Trigger: `Subscription cancelled` - Condition: cancellation reason = "too expensive" - Action: Send Slack message to `#retention` with customer details Lets the retention team reach out manually to high-LTV cancellations. ### Klaviyo flow: post-cancel save - Trigger: `Subscription cancelled` - Action: Send custom event to Klaviyo (`Subscription Cancelled`) - Klaviyo: triggers a 7-day re-engagement flow ## Flow vs. webhooks Flow is the right choice when the downstream action is a Shopify-native thing (tags, fulfillment, email via Klaviyo flows). Webhooks are the right choice when you need to hit a custom internal system with structured data. Many merchants use both. --- title: Install eventabee url: https://honeybound.co/work/eventabee/guides/install app: eventabee category: getting-started summary: Install from the Shopify App Store, grant scopes, and open the dashboard. --- Start here when you are installing eventabee on a Shopify store for the first time. ![eventabee dashboard after installation](/static/guides/eventabee/dashboard.png) ## 1. Install from the Shopify App Store 1. Open [apps.shopify.com/eventabee](https://apps.shopify.com/eventabee). 2. Click **Install** and choose the Shopify store you want to connect. 3. Review the requested permissions and continue. eventabee uses Shopify's app install flow. If Shopify asks you to log in or pick a staff account, use an account that can install apps and edit the theme. ## 2. Grant the requested scopes Shopify shows the scopes before the app is installed. Approve them to let eventabee receive store events, manage the app embed/pixel integration, and show the in-admin dashboard. ## 3. Open the eventabee dashboard After installation, Shopify redirects you into eventabee. You should see the app sidebar with these main areas: - **Dashboard** — recent event and delivery health. - **Live Events** — a real-time stream for testing. - **Event Log** — historical events and delivery details. - **Destinations** — Meta, Google, TikTok, webhook, and requested destination setup. - **Consent Banner** — banner appearance, consent categories, and privacy behavior. ## 4. Verify your store Check the shop name shown at the bottom of the sidebar. It should match the Shopify store you installed on, for example `innovonics-dev.myshopify.com` in the screenshot above. ## Next steps 1. [Install the Theme App Embed](/work/eventabee/guides/theme-embed) 2. [Verify events are flowing](/work/eventabee/guides/verify-events) 3. [Connect your first destination](/work/eventabee/guides/destination-meta) --- title: Install the theme app embed url: https://honeybound.co/work/eventabee/guides/theme-embed app: eventabee category: getting-started summary: Enable the Theme App Embed that ships the consent banner and browser-side pixel. --- The eventabee theme app embed loads the storefront consent banner and browser-side helpers. The Shopify Web Pixel extension handles Shopify customer events; the theme embed makes the banner and script/cookie controls available on your storefront. ## 1. Open the theme editor 1. From Shopify Admin, go to **Online Store → Themes**. 2. On your live theme, click **Customize**. 3. In the theme editor left sidebar, open **App embeds**. ## 2. Enable the eventabee app embed 1. Find **eventabee Analytics**. 2. Turn it on. 3. If your theme shows separate eventabee blocks, keep both analytics/consent pieces enabled unless support tells you otherwise. ## 3. Save and publish Click **Save** in the theme editor. Then open your storefront in a fresh/incognito browser window and load any public page. ## 4. Confirm in eventabee ![eventabee Live Events page](/static/guides/eventabee/live-events.png) Open **Live Events** in eventabee and refresh the storefront. A `page_view` should appear within a few seconds. If it does not, continue with [Verify events are flowing](/work/eventabee/guides/verify-events). ## Why a theme app embed instead of a script tag? App embeds are managed by Shopify, survive theme updates better than hand-pasted scripts, and are easier to disable safely if you ever uninstall the app. ## Next [Customize the consent banner](/work/eventabee/guides/consent-banner) --- title: Verify events are flowing url: https://honeybound.co/work/eventabee/guides/verify-events app: eventabee category: getting-started summary: Confirm storefront events are flowing before connecting destinations. --- Use this guide immediately after installation and whenever you are checking a new theme or destination. ![eventabee Live Events stream](/static/guides/eventabee/live-events.png) ## 1. Open Live Events In eventabee, click **Live Events** in the sidebar. This page streams new events as they arrive. The sidebar status indicator also shows whether the live stream is connected and the recent events-per-minute rate. ## 2. Trigger a page view 1. Open your storefront in a separate browser tab or incognito window. 2. Visit the home page or any product page. 3. Return to **Live Events** and look for a recent page-view style event. If you do not see anything, make sure the **eventabee Analytics** theme app embed is enabled and saved. ## 3. Check the Event Log ![eventabee Event Log](/static/guides/eventabee/event-log.png) Open **Event Log** to confirm events are being stored, not just streamed. The log is the best place to inspect event IDs, timestamps, event type, and downstream delivery status. ## 4. Trigger a transactional event For deeper testing, trigger an add-to-cart or test checkout event from the storefront. Shopify may require a real test order flow for purchase events; use Shopify's test payment method or a development store workflow where appropriate. ## Troubleshooting - **No events in Live Events:** confirm the app embed is enabled, then hard-refresh the storefront. - **Live Events works but a destination has no deliveries:** open **Destinations**, make sure the destination is **Active**, and check its **Consent Category**. - **Events are consent-blocked:** configure the consent banner and test with accepted analytics/marketing categories. - **Only some event types appear:** Shopify only emits certain events after the relevant customer action happens. ## Next [Connect your first destination](/work/eventabee/guides/destination-meta) --- title: Set up the consent banner url: https://honeybound.co/work/eventabee/guides/consent-banner app: eventabee category: consent-privacy summary: Enable, style, regionalize, and verify the storefront consent banner. --- The consent banner controls which storefront events can be sent to analytics, marketing, and functional destinations. Open **Consent Banner** from the eventabee sidebar. ![eventabee Consent Banner settings](/static/guides/eventabee/consent-banner.png) ## 1. Enable the banner In the **General** card, check **Enable consent banner**. Choose the banner position that best fits your theme: - Bottom bar - Bottom left - Bottom right - Center modal - Top bar ## 2. Customize appearance In **Style**, set the background color, text color, primary/secondary button colors, border radius, and font family. Use your storefront brand colors, but keep contrast high enough for accessibility. ## 3. Choose per-region layouts In **Buttons & Layout**, choose a layout for each privacy regime: - **EU & UK (GDPR):** three-button, reject-first, or two-button layouts. Single-accept and nested reject patterns are intentionally unavailable here. - **US state privacy laws:** layouts must include a clear opt-out path. - **Everywhere else:** all layouts are available, including implied-consent options. You can customize the labels for **Accept**, **Reject**, **Customize**, **Save preferences**, and the manage-preferences link. ## 4. Edit banner copy and categories In **Content**, update the headline, description, and category labels/descriptions: - Functional - Analytics - Marketing Also add your **Privacy Policy URL** and **Cookie Policy URL** so visitors can review your full policy. ## 5. Configure behavior Use the **Behavior**, **Dismissal Behavior**, **Preferences Re-entry**, and **Global Privacy Control (GPC)** sections to control: - Whether the banner appears on first visit. - How many days before it reappears. - Whether US/rest-of-world visitors can close the banner. - Whether an X means **Reject** or temporary **Dismiss** where legally allowed. - Whether a floating **Cookie Settings** button appears. - How GPC signals are handled for US opt-out states. ## 6. Save and verify Use the save bar to save your changes, then open the storefront in a fresh/incognito browser window. Accept, reject, and customize preferences to verify the banner behaves as expected. ## Related policy guides - [Privacy policy additions](/work/eventabee/guides/privacy-policy) - [Cookie policy additions](/work/eventabee/guides/cookie-policy) - [Regional privacy notes](/work/eventabee/guides/regional-privacy-notes) --- title: Privacy policy additions for eventabee url: https://honeybound.co/work/eventabee/guides/privacy-policy app: eventabee category: consent-privacy summary: What to add to your store's privacy policy when you install eventabee. --- Add an eventabee disclosure to your store privacy policy when you use eventabee to collect events, manage consent, or forward events to analytics/marketing destinations. ## What to disclose Your policy should explain: - eventabee helps collect storefront events such as page views, product views, add-to-cart actions, checkouts, and purchases. - eventabee may process identifiers, device/browser data, order/customer context, and consent preferences. - eventabee forwards eligible events only to the destinations you configure, subject to consent settings. - Visitors can manage consent through your banner or cookie-settings link. ## Sample clause > We use eventabee to help measure storefront activity, manage privacy preferences, and send eligible events to analytics and advertising tools we configure. eventabee may process information such as browser/device identifiers, page and product activity, order context, and consent choices. Events are shared with selected destinations only as permitted by our consent settings and applicable law. ## Destination list List the destinations you enable, for example Meta, Google Analytics/Ads, TikTok, webhooks, or approved first-party connectors. ## When to update Update your policy when you add a new destination, change consent categories, enable marketing activation, or change how visitors can manage preferences. ## See also - [Cookie policy additions](/work/eventabee/guides/cookie-policy) - [Regional privacy notes](/work/eventabee/guides/regional-privacy-notes) --- title: Privacy policy disclosures for eventabee merchants url: https://honeybound.co/work/eventabee/guides/privacy-disclosure-guide app: eventabee category: consent-privacy summary: Copy-paste templates for adding eventabee + your ad-platform destinations to your store's privacy policy. --- Use these copy-paste templates to update your store's privacy policy when you install eventabee and connect destinations. This is not legal advice; have counsel review the final policy. ## What to add (everyone) > We use eventabee to help collect storefront events, manage privacy preferences, and send eligible events to analytics and advertising destinations we configure. eventabee may process browser/device identifiers, page and product activity, cart/checkout/order context, and consent choices. Events are shared with selected destinations only according to our consent settings and applicable law. ## If you've connected Meta (Facebook / Instagram) > We may send eligible events to Meta for conversion measurement, ad attribution, and campaign optimization. These events may include event names, timestamps, browser identifiers, order context, and hashed customer information where available and permitted. ## If you've connected Google (Ads / Analytics 4) > We may send eligible events to Google Analytics 4 and/or Google Ads for measurement, attribution, and reporting. Google may process event and device data according to our Google configuration and visitor consent choices. ## If you've connected TikTok > We may send eligible events to TikTok for conversion measurement and campaign optimization, subject to visitor consent and our advertising settings. ## If you've connected Pinterest, Snapchat, Klaviyo, PostHog, Segment, or another connector Add a short paragraph naming each destination and explaining whether it is used for analytics, advertising, email/SMS segmentation, product analytics, or internal operations. ## CCPA "Do Not Sell or Share My Personal Information" If your use of advertising or analytics destinations is considered sale/share or targeted advertising, make sure your policy and consent banner provide a clear opt-out path. eventabee's US privacy mode and GPC behavior can help support this workflow. ## Updating your policy when you add a destination Each time you add a destination in eventabee, update your policy and cookie table before sending production traffic to that destination. ## Questions For product questions, contact [support@eventabee.com](mailto:support@eventabee.com). For legal wording, consult your counsel. --- title: Cookie policy additions url: https://honeybound.co/work/eventabee/guides/cookie-policy app: eventabee category: consent-privacy summary: Cookie categories and descriptions to disclose when using eventabee. --- This guide helps you add eventabee-related cookie disclosures to your store's cookie policy. It is not legal advice; have counsel review your final policy. ## Cookies set by eventabee eventabee may use storefront storage/cookies to remember consent choices, support privacy preferences, and connect browser-side activity with server-side event delivery. Your policy should explain that these identifiers help measure site usage, attribution, and consent state. ## Downstream destination cookies Destinations such as Meta, Google, TikTok, Pinterest, Snapchat, Klaviyo, PostHog, Segment, or webhook receivers may set or rely on their own cookies, pixels, or identifiers. Disclose each destination you enable. ## Sample table | Category | Purpose | Examples | | --- | --- | --- | | Essential / functional | Remember consent choices and keep privacy controls working | eventabee consent/preferences identifiers | | Analytics | Measure storefront visits, product views, and funnel activity | GA4, PostHog, Segment | | Marketing | Measure and optimize advertising, retargeting, and conversion reporting | Meta, Google Ads, TikTok, Pinterest, Snapchat | ## Keep this updated Revisit the table whenever you add, remove, or change a destination in eventabee. ## See also - [Privacy policy additions](/work/eventabee/guides/privacy-policy) - [Consent banner setup](/work/eventabee/guides/consent-banner) --- title: Regional privacy notes url: https://honeybound.co/work/eventabee/guides/regional-privacy-notes app: eventabee category: consent-privacy summary: GDPR, UK GDPR, and US state laws — a plain-English field guide. --- eventabee's consent banner uses regional modes so visitors see an experience appropriate for their privacy regime. This guide is a plain-English field guide, not legal advice. ## European Economic Area (EEA), UK, Switzerland Use opt-in consent for analytics and marketing. Reject must be as easy to find as Accept, which is why eventabee locks out single-accept and hidden-reject layouts for this region. ## California (CCPA / CPRA) Provide a clear opt-out mechanism for sale/share or targeted advertising. eventabee's US opt-out mode supports clear reject/customize flows and Global Privacy Control handling. ## Other US states with opt-out laws Several US states require opt-out rights for targeted advertising or sale/share style processing. Use the US state privacy mode for these visitors. ## Rest of world Where no specific opt-in/opt-out regime applies, eventabee can show an implied-consent layout. You may still choose a stricter layout for brand trust or internal policy reasons. ## Data Subject Requests (DSRs) If a visitor requests access/deletion/export, use your Shopify/customer records and any eventabee DSR tooling available on your plan. Keep destination processors in sync with your deletion/export workflow. ## See also - [Consent banner setup](/work/eventabee/guides/consent-banner) - [Privacy policy additions](/work/eventabee/guides/privacy-policy) --- title: Connect Meta (Conversions API) url: https://honeybound.co/work/eventabee/guides/destination-meta app: eventabee category: destinations summary: Set up Meta CAPI with access token, dataset ID, and test events. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Create a system user and access token in Meta In Meta Business Manager, create or use a system user with access to the dataset/pixel. Generate a token with Conversions API permissions. ## 2. Find your Dataset / Pixel ID In Meta Events Manager, open the dataset or pixel connected to your ad account and copy the ID. ## 3. Paste into eventabee In the Meta destination editor, fill in: - **Pixel ID** — required. - **Access Token** — required; stored as a secret and hidden after save. - **Test Event Code** — optional; use while validating in Meta's Test Events tool, then clear it for production. - **Consent Category** — normally **Marketing**. ## 4. Save and verify Trigger a page view or test checkout event, then check **Event Log** in eventabee and **Test Events** in Meta Events Manager. ## Troubleshooting - Invalid token errors usually mean the system user does not have access to the dataset. - No events in Meta but deliveries in eventabee usually means the Meta test code is missing or you are looking at the wrong dataset. - Consent-blocked deliveries mean the visitor did not grant the destination's consent category. --- title: Connect Google (GA4 + Ads) url: https://honeybound.co/work/eventabee/guides/destination-google app: eventabee category: destinations summary: Send events to GA4 via Measurement Protocol and plan Google Ads setup carefully. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## GA4 setup ## 1. Create a Measurement Protocol API secret In Google Analytics 4, open **Admin → Data streams → Web stream → Measurement Protocol API secrets** and create a new secret for eventabee. ## 2. Find your Measurement ID In the same GA4 web stream, copy the Measurement ID. It usually starts with `G-`. ## 3. Paste into eventabee In the Google destination editor, fill in: - **Measurement ID** — required. - **API Secret** — required; stored as a secret and hidden after save. - **Consent Category** — normally **Analytics** for GA4. If you are using Google Ads conversion fan-out from the same destination, use **Marketing** or confirm the consent mapping with support. ## Google Ads Enhanced Conversions The current merchant UI exposes the GA4 Measurement Protocol fields directly. Google Ads-specific conversion IDs, labels, and enhanced-conversion mappings may be handled through reviewed advanced configuration or a support-assisted setup, depending on your plan and destination configuration. ## Verify Trigger a storefront event, then check **Event Log** in eventabee and GA4's realtime/debug views. Measurement Protocol events can take time to appear in standard GA4 reports. ## Troubleshooting - `measurement_id` should look like `G-XXXXXXXXXX`. - A wrong API secret can produce delivery failures in the event log. - Consent-blocked events require the visitor to grant the destination's consent category. --- title: Connect TikTok (Events API) url: https://honeybound.co/work/eventabee/guides/destination-tiktok app: eventabee category: destinations summary: Set up TikTok Events API with pixel code and access token. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Create a Pixel in TikTok Events Manager In TikTok Events Manager, create or open the pixel you want eventabee to send server events to. ## 2. Generate an access token Generate an Events API access token for that pixel. ## 3. Paste into eventabee In the TikTok destination editor, fill in: - **Pixel ID** — required. - **Access Token** — required; stored as a secret and hidden after save. - **Test Event Code** — optional for validation. - **Consent Category** — normally **Marketing**. ## 4. Verify Trigger storefront activity and check **Event Log** in eventabee plus TikTok's Events Manager testing tools. ## Troubleshooting - Leave the test event code blank for production traffic. - If TikTok receives events without attribution, confirm your storefront is collecting enough browser/session identifiers and that consent allows marketing events. --- title: Connect Klaviyo url: https://honeybound.co/work/eventabee/guides/destination-klaviyo app: eventabee category: destinations summary: Request or configure Klaviyo delivery and verify event flow. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Confirm availability Klaviyo may not appear in the standard **Add Destination** type menu. If it is not visible, open **Request a destination** from the Destinations page and submit the vendor, account details, intended events, and consent category. ## 2. Gather credentials Prepare the required credential set for Klaviyo: **Private API Key**. Keep tokens private and paste them only into eventabee's destination editor or a secure support channel when requested. ## 3. Configure after provisioning Once the connector is enabled for your store, click **Edit** on the destination and complete the structured fields. Set **Consent Category** to **Marketing** for advertising/activation tools, or **Analytics** for analytics-only use cases. ## 4. Verify Trigger a storefront event, open **Event Log**, and confirm the delivery row is sent successfully. Then verify the event in Klaviyo's own event/debug view. ## Troubleshooting - If the destination type is missing, use the request flow instead of trying to force a webhook unless the vendor specifically supports generic webhooks. - If credentials were saved previously, secret fields show as filled; leave them blank when editing to keep the existing secret. - Consent-blocked deliveries mean the visitor did not grant the selected consent category. --- title: Connect Pinterest (Conversions API) url: https://honeybound.co/work/eventabee/guides/destination-pinterest app: eventabee category: destinations summary: Request or configure Pinterest delivery and verify event flow. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Confirm availability Pinterest may not appear in the standard **Add Destination** type menu. If it is not visible, open **Request a destination** from the Destinations page and submit the vendor, account details, intended events, and consent category. ## 2. Gather credentials Prepare the required credential set for Pinterest: **Ad Account ID and Access Token**. Keep tokens private and paste them only into eventabee's destination editor or a secure support channel when requested. ## 3. Configure after provisioning Once the connector is enabled for your store, click **Edit** on the destination and complete the structured fields. Set **Consent Category** to **Marketing** for advertising/activation tools, or **Analytics** for analytics-only use cases. ## 4. Verify Trigger a storefront event, open **Event Log**, and confirm the delivery row is sent successfully. Then verify the event in Pinterest's own event/debug view. ## Troubleshooting - If the destination type is missing, use the request flow instead of trying to force a webhook unless the vendor specifically supports generic webhooks. - If credentials were saved previously, secret fields show as filled; leave them blank when editing to keep the existing secret. - Consent-blocked deliveries mean the visitor did not grant the selected consent category. --- title: Connect Snapchat (Conversions API) url: https://honeybound.co/work/eventabee/guides/destination-snapchat app: eventabee category: destinations summary: Request or configure Snapchat delivery and verify event flow. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Confirm availability Snapchat may not appear in the standard **Add Destination** type menu. If it is not visible, open **Request a destination** from the Destinations page and submit the vendor, account details, intended events, and consent category. ## 2. Gather credentials Prepare the required credential set for Snapchat: **Pixel ID, Access Token, and optional Test Event Code**. Keep tokens private and paste them only into eventabee's destination editor or a secure support channel when requested. ## 3. Configure after provisioning Once the connector is enabled for your store, click **Edit** on the destination and complete the structured fields. Set **Consent Category** to **Marketing** for advertising/activation tools, or **Analytics** for analytics-only use cases. ## 4. Verify Trigger a storefront event, open **Event Log**, and confirm the delivery row is sent successfully. Then verify the event in Snapchat's own event/debug view. ## Troubleshooting - If the destination type is missing, use the request flow instead of trying to force a webhook unless the vendor specifically supports generic webhooks. - If credentials were saved previously, secret fields show as filled; leave them blank when editing to keep the existing secret. - Consent-blocked deliveries mean the visitor did not grant the selected consent category. --- title: Connect Segment url: https://honeybound.co/work/eventabee/guides/destination-segment app: eventabee category: destinations summary: Request or configure Segment delivery and verify event flow. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Confirm availability Segment may not appear in the standard **Add Destination** type menu. If it is not visible, open **Request a destination** from the Destinations page and submit the vendor, account details, intended events, and consent category. ## 2. Gather credentials Prepare the required credential set for Segment: **Write Key**. Keep tokens private and paste them only into eventabee's destination editor or a secure support channel when requested. ## 3. Configure after provisioning Once the connector is enabled for your store, click **Edit** on the destination and complete the structured fields. Set **Consent Category** to **Marketing** for advertising/activation tools, or **Analytics** for analytics-only use cases. ## 4. Verify Trigger a storefront event, open **Event Log**, and confirm the delivery row is sent successfully. Then verify the event in Segment's own event/debug view. ## Troubleshooting - If the destination type is missing, use the request flow instead of trying to force a webhook unless the vendor specifically supports generic webhooks. - If credentials were saved previously, secret fields show as filled; leave them blank when editing to keep the existing secret. - Consent-blocked deliveries mean the visitor did not grant the selected consent category. --- title: Connect PostHog url: https://honeybound.co/work/eventabee/guides/destination-posthog app: eventabee category: destinations summary: Request or configure PostHog delivery and verify event flow. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Confirm availability PostHog may not appear in the standard **Add Destination** type menu. If it is not visible, open **Request a destination** from the Destinations page and submit the vendor, account details, intended events, and consent category. ## 2. Gather credentials Prepare the required credential set for PostHog: **Project API Key / project configuration**. Keep tokens private and paste them only into eventabee's destination editor or a secure support channel when requested. ## 3. Configure after provisioning Once the connector is enabled for your store, click **Edit** on the destination and complete the structured fields. Set **Consent Category** to **Marketing** for advertising/activation tools, or **Analytics** for analytics-only use cases. ## 4. Verify Trigger a storefront event, open **Event Log**, and confirm the delivery row is sent successfully. Then verify the event in PostHog's own event/debug view. ## Troubleshooting - If the destination type is missing, use the request flow instead of trying to force a webhook unless the vendor specifically supports generic webhooks. - If credentials were saved previously, secret fields show as filled; leave them blank when editing to keep the existing secret. - Consent-blocked deliveries mean the visitor did not grant the selected consent category. --- title: Connect a generic webhook url: https://honeybound.co/work/eventabee/guides/destination-webhook app: eventabee category: destinations summary: Forward events to an HTTPS endpoint with optional authorization and retries. --- Open **Destinations** in eventabee before starting this guide. ![eventabee Destinations page](/static/guides/eventabee/destinations.png) Click **Add Destination**, choose the destination type when it is available, give it a clear name, and save it. Then click **Edit** on the destination to fill in the structured fields and set the consent category. If the type is not shown in the **Add Destination** menu, use **Request a destination** instead. eventabee currently exposes Meta, Google Analytics / Ads, TikTok, and Webhook directly in the add form; additional first-party connectors can be provisioned after review. ## 1. Add the destination Click **Add Destination**, choose **Webhook**, enter a clear name, and save. ## 2. Enter the endpoint URL Click **Edit** and fill in **Endpoint URL**. Use an HTTPS endpoint that can accept JSON POST requests. ## 3. Add authentication if needed Fill in **Authorization Header** if your receiver requires it, for example: ```text Bearer your-token-here ``` eventabee stores this as sensitive config. After saving, leave the field blank if you want to keep the existing value. ## 4. Consent category Choose the category that matches what the webhook does: - **Analytics** for internal analytics pipelines. - **Marketing** for ad/retargeting/activation systems. - **Functional** for non-marketing customer experience tools. - **Essential** only when the destination is strictly necessary. ## 5. Advanced JSON Business-plan stores may see **Advanced Config (JSON)**. Use it only for support-approved options; the standard UI does not provide a separate event-filter builder. ## Retries and verification Trigger a storefront event and inspect **Event Log**. Failed webhook deliveries are retried automatically, and failed rows can be retried from their delivery detail where available. ## Troubleshooting - Your endpoint must return a 2xx response for success. - Keep response bodies small and avoid returning secrets. - If a firewall is in front of the endpoint, allow eventabee's outbound traffic or use a public HTTPS receiver. --- title: Request a first-party destination url: https://honeybound.co/work/eventabee/guides/destination-custom app: eventabee category: destinations summary: Request a new integration or use a webhook when a vendor is not built in. --- Use this guide when the standard **Add Destination** menu does not include the vendor you need, or when a generic webhook cannot meet the vendor's API requirements. ![eventabee Destinations page with destination tools](/static/guides/eventabee/destinations.png) ## 1. Check generic webhooks first If the vendor can receive a JSON POST at an HTTPS endpoint, start with [Connect a generic webhook](/work/eventabee/guides/destination-webhook). Webhooks are fastest when the receiver owns mapping, auth, and validation. ## 2. Gather vendor requirements Before submitting a request, collect: - Vendor name and documentation URL. - Required account IDs, pixel IDs, dataset IDs, or write keys. - Authentication method. - Required event names and payload fields. - Consent category: functional, analytics, or marketing. - Any test-event or sandbox workflow. ## 3. Submit the request Open **Destinations → Request a destination**. Describe the use case and include links to the vendor docs. Do not paste long-lived secrets into a free-text field unless support has explicitly asked you to do so through a secure flow. ## 4. Validate delivery After the connector is provisioned, trigger events from the storefront, inspect **Event Log**, and verify the vendor's own debug/event-history view. ## When to use webhook vs. request flow - Use **Webhook** for internal systems, serverless functions, warehouses, or automation tools that already accept eventabee-shaped JSON. - Use **Request a destination** when the vendor needs a signed payload, vendor-specific event names, specific consent handling, or a reviewed first-party integration. --- title: Replay and backfill url: https://honeybound.co/work/eventabee/guides/replay-backfill app: eventabee category: operations summary: Understand retry, replay, and support-assisted backfill after configuration fixes. --- Replay and backfill are recovery workflows for events that were received by eventabee but need to be delivered again after a configuration change. ![eventabee Event Log used for replay investigations](/static/guides/eventabee/event-log.png) ## When replay matters ### 1. Destination token rotation If a token expired or was revoked, update the destination credentials first. New events should start delivering immediately; older failed deliveries can be retried where the UI offers a retry action. ### 2. Consent upgrades If a visitor grants additional consent after an earlier visit, eventabee can use stored consent/event context for eligible recovery paths. Availability depends on the event, retention window, and destination rules. ### 3. New destination connection A newly connected destination receives new eligible events going forward. Historical backfill is not automatic from the merchant UI. ## How to replay 1. Open **Event Log** and identify the affected event or destination. 2. Fix the root cause: credentials, endpoint URL, consent category, or vendor permissions. 3. Retry failed deliveries from the delivery detail where available. 4. For bulk replay/backfill, contact support with the date range, event types, destination, and reason. ## Backfill tagging Backfilled deliveries are tracked separately in eventabee's delivery data so support can distinguish normal live delivery from recovery runs. ## Retention and caveats Replay is limited by retention, consent state, vendor API rules, and idempotency/deduplication behavior. Do not use replay to create duplicate conversions unless support confirms the destination will dedupe correctly. --- title: Debug a destination url: https://honeybound.co/work/eventabee/guides/debugging-destinations app: eventabee category: operations summary: Use the Event Log, delivery details, retries, and support replay paths. --- Use **Event Log**, destination detail rows, and failed-delivery retry actions to diagnose destination problems. ![eventabee Event Log for delivery debugging](/static/guides/eventabee/event-log.png) ## The event log Open **Event Log** and click an event to inspect its details. Use it to answer: - Did eventabee receive the event? - Which destinations were eligible? - Was delivery sent, waiting, failed, or consent-blocked? - What response code or error message came back from the destination? ## Failed deliveries and retries eventabee retries transient failures automatically. Failed delivery rows expose retry/attempt details in the admin UI where available. Use retry after fixing credentials, endpoint URLs, destination permissions, or vendor-side outages. ## Common failure modes - **401/403:** token is invalid, expired, or lacks access to the account/dataset/pixel. - **404:** wrong endpoint, dataset, pixel, or account ID. - **429:** vendor rate limit. Wait and let retries continue. - **400:** payload rejected; check required fields and whether the vendor supports that event type. - **Consent blocked:** the visitor has not granted the destination's consent category. ## No separate DLQ page The merchant UI surfaces failed/exhausted delivery state through delivery/event views rather than a standalone dead-letter-queue page. For bulk replay or unusual recovery, contact support with the event IDs and destination name. ## Partial outages If only one destination is failing, leave other active destinations enabled. Fix the failing destination, then retry or request replay for the affected rows. --- title: How event deduplication works url: https://honeybound.co/work/eventabee/guides/dedup-events app: eventabee category: operations summary: Use consistent event IDs so browser and server signals do not double-count. --- eventabee is designed so browser-side and server-side signals can be reconciled without double-counting conversions. ![eventabee Event Log showing event IDs](/static/guides/eventabee/event-log.png) ## The pattern Each tracked event carries an event ID. Destination integrations use that ID, plus destination-specific identifiers where supported, so platforms such as Meta, TikTok, Google, and other connectors can deduplicate browser and server events. ## What you need to do - Keep the Shopify Web Pixel and eventabee theme app embed enabled. - Do not install duplicate manual eventabee snippets. - Use one active destination per ad account/pixel unless support recommends otherwise. - Leave destination event IDs untouched in advanced config. ## How to check dedup is working 1. Trigger a storefront event. 2. Open **Event Log** and inspect the event ID and destination deliveries. 3. Check the destination's diagnostics/debug tool for deduplication or event-match status. ## Per-destination behavior Each vendor reports deduplication differently. Meta and TikTok expose event/test tools; GA4 and other analytics tools may show data only after processing delays. ## Edge cases - Duplicate Shopify pixels or old manual snippets can create duplicates. - Test-event modes can change where events appear in vendor dashboards. - Backfills/replays should be used carefully because not every vendor dedupes every event type the same way. --- title: Install searchabee url: https://honeybound.co/work/searchabee/guides/install app: searchabee category: getting-started summary: Install from Shopify, grant scopes, and wait for the initial catalog sync. --- searchabee installs into any Shopify store via the standard install flow. The app provisions a per-shop Meilisearch index on first install, then watches Shopify webhooks to keep it in sync. ## 1. Install During beta we send a direct install link. Click it from a browser signed in to the target store. ## 2. Grant scopes searchabee requests scopes to read products, collections, and metafields (needed to build the search index and filter trees), plus the Theme App Extension scope for storefront rendering. ## 3. Initial catalog sync On first install searchabee backfills your catalog into a dedicated Meilisearch index. Depending on catalog size this takes seconds to a few minutes. The dashboard shows progress live. ## 4. Add the theme block Open your theme in the Shopify Admin theme editor, add the searchabee block to your collection template, and save. You'll see filter and sort controls on your collection pages immediately. ## Next steps - [Configure filter trees](/work/searchabee/guides/filter-trees) - [Bind filters to collection templates](/work/searchabee/guides/theme-app-extension) - [Tune search relevance](/work/searchabee/guides/search-config) --- title: Define filter trees url: https://honeybound.co/work/searchabee/guides/filter-trees app: searchabee category: getting-started summary: Configure the filter structure shoppers see on collection pages. --- A filter tree is the structured set of facets shoppers see on a collection page: Size, Color, Brand, Material, Price, etc. searchabee lets you define multiple trees and bind each to specific collection templates so different collection types can have different filter structures. ## 1. Open the editor searchabee console → **Filters → Trees**. ## 2. Create a tree Name it (e.g., "Apparel default", "Electronics", "Sale collections") and click Create. You start with an empty tree. ## 3. Add filter sources Filter sources are where the filter values come from. searchabee supports four types: - **Product option** — Shopify product options like Size, Color, Material. Values come from the option's variant set. - **Product field** — Vendor, product type, tags. Simple. - **Variant field** — Availability, price range. Computed per variant. - **Category metafield** — A metafield on the product or a taxonomy; useful for attributes not modeled as options (gender, fit, season). For each source, configure: - **Display name** (what shoppers see) - **Display type** (checkboxes, swatches, range slider for price) - **Sort order** (alphabetical, count descending, manual) - **Visibility rules** (hide if <2 values, show only on specific collections) ## 4. Bind to collection templates In **Filters → Template bindings**, assign each tree to one or more collection templates. Most stores have 1–2 templates (default and landing); searchabee lets you target precisely. Example binding: `collection.apparel.json` template → "Apparel default" tree. Any collection page using that template will show that tree. ## 5. Preview Click **Preview** next to any tree to see it render against a sample collection. The preview uses your actual index, so filter counts are real. ## Tips - Start simple — three to five filters per tree. More becomes paralysis. - Price range belongs on almost every tree. - Availability ("In stock") is low-friction and high-conversion — always include it. ## Next - [Bind filters to collection templates](/work/searchabee/guides/theme-app-extension) - [Tune search relevance](/work/searchabee/guides/search-config) --- title: Add the theme block url: https://honeybound.co/work/searchabee/guides/theme-app-extension app: searchabee category: getting-started summary: Install the searchabee block into your collection template. --- The searchabee theme block renders the filter UI on your storefront. It's a Shopify Theme App Extension, so it installs via the standard theme editor. ## 1. Open the theme editor Shopify Admin → **Online Store → Themes → Customize**. ## 2. Navigate to a collection template In the template picker (top bar), switch to **Collections → Default collection** (or whichever template you want to configure). ## 3. Add the searchabee block In the left sidebar, find the **Products grid** section (name varies by theme). Above or next to it, click **Add block** and choose **searchabee Filters**. ## 4. Position Drag the block to where you want it to render — typically as a left sidebar on desktop and above the grid on mobile. The block is responsive and respects your theme's container widths. ## 5. Block settings - **Filter tree:** pick which tree to render (from the ones you've defined in the dashboard). - **Sort options:** choose which sort options are visible (relevance, price, newest, best-selling). - **Initial state:** expanded or collapsed on mobile. ## 6. Save and test Save the theme. Visit the collection page on the live storefront. You should see filters render with real counts, and applying them should update the product grid without a full page reload. ## Replace Shopify's native filters Many themes ship with Shopify's native filter block enabled by default. Disable that block — having two filter UIs is confusing. searchabee does everything the native block does, plus catalog-wide scope. ## Custom themes If your theme doesn't have a standard "Products grid" section, you can still add the block to any section that renders collection products. Reach out if the block isn't appearing as expected — we've tested against major themes but custom themes sometimes need a one-line adjustment. --- title: Handling large catalogs url: https://honeybound.co/work/searchabee/guides/large-catalogs app: searchabee category: operations summary: Indexing, memory, and performance notes for catalogs past 5k SKUs. --- searchabee is built for catalogs that outgrow Shopify's native page-scoped filters. This guide covers what to expect at scale. ## Index size Each shop gets a dedicated Meilisearch index. Index size roughly scales linearly with: - Number of products + variants - Number of indexed fields (more fields = larger index) - Filter source count (each adds a faceted attribute) A typical 50k-SKU apparel catalog indexes to ~500MB. A 200k-SKU catalog indexes to ~2GB. Meilisearch handles both well. ## Sync performance Initial backfill processes Shopify's GraphQL catalog API. Expect: - 10k SKUs → ~2 minutes - 50k SKUs → ~8 minutes - 200k SKUs → ~30 minutes After backfill, incremental sync is webhook-driven and completes in seconds. ## Query latency Meilisearch typical latency at catalog sizes we target: - 10k SKUs: sub-5ms - 100k SKUs: sub-15ms - 500k SKUs: sub-30ms These are index-side times. Add ~30–80ms of network round trip from the shopper's browser to our API. ## Best practices - **Limit indexed fields.** Each added field (beyond the defaults) adds latency. Only index what you actually filter/sort/search on. - **Use metafield filters sparingly.** Metafields are the heaviest source type because they require denormalizing. Prefer product fields and options where possible. - **Avoid deeply nested filter trees.** Past 15 filters per tree, shoppers rarely scroll that far. Consolidate. - **Rebuild rarely.** Our sync is incremental. Triggering a full rebuild is a last resort, not a regular operation. ## Monitoring searchabee console → **Health** shows index size, last sync time, and recent query latency percentiles. If latency p95 starts creeping up, reach out — often it's addressable by dropping an unused filter source. --- title: How webhook sync works url: https://honeybound.co/work/searchabee/guides/webhook-sync app: searchabee category: operations summary: Shopify webhooks drive the per-shop index. Understanding the flow. --- searchabee's index stays fresh via Shopify webhooks. Understanding the flow helps when something looks off. ## Webhooks we subscribe to - `products/create`, `products/update`, `products/delete` - `collections/create`, `collections/update`, `collections/delete` - `inventory_levels/update` - `product_listings/add`, `product_listings/remove` (for publishing state) Each webhook fires a differential update to the shop's Meilisearch index. Typical end-to-end latency (webhook → index updated → next query sees change): 2–5 seconds. ## What happens on each event ### `products/update` 1. Webhook arrives at searchabee. 2. searchabee fetches the full product via GraphQL (webhook payloads are often partial). 3. Transforms to the indexed shape (variants flattened, filter fields extracted). 4. Upserts into the Meilisearch index. ### `inventory_levels/update` 1. Webhook arrives. 2. If any searchabee filter source depends on availability, the affected variant's document is updated. 3. Otherwise no-op (saves cycles). ## What this means operationally - **Bulk imports** fire a lot of webhooks quickly. searchabee queues them on Redis Streams and processes at a steady rate, respecting Shopify's webhook rate limit tolerance. You may see a few seconds of index lag during a 10k-product import. - **Draft products** are excluded. If a product is not published to the Online Store channel, it's not in the index. - **Soft-deleted products** (deleted then restored) re-appear in the index on the next webhook. ## Debugging sync searchabee console → **Sync → Activity** shows every webhook received, the action taken, and the resulting index state. Filter by product ID to see the history for a specific SKU. If a product seems to be stale in the index: 1. Check Activity — did the webhook arrive? If not, it's a Shopify-side issue (check Shopify Admin → Notifications → Webhooks). 2. Force-sync that product: **Products → [product] → Resync**. This triggers a direct GraphQL pull and upsert, bypassing webhook. ## Full resync A full resync rebuilds the entire index from scratch. Only do this when: - You've restructured filter trees and need to re-derive attributes. - The index is demonstrably corrupted (rare). **Sync → Rebuild index** triggers it. Expect the initial-backfill timings from the [large catalogs guide](/work/searchabee/guides/large-catalogs). --- title: Debug index freshness url: https://honeybound.co/work/searchabee/guides/debugging-index-freshness app: searchabee category: operations summary: A product on the storefront doesn't match the product in Shopify — diagnose it. --- If a shopper sees stale data — wrong price, out-of-stock item showing as available, a discontinued product still listed — the root cause is always one of three things. Here's how to walk them down. ## 1. Did Shopify actually save the change? Open the product in Shopify Admin. Does the product page show the change? If not, it's a Shopify save issue (connection, validation, unsaved draft). Fix in Shopify first. ## 2. Did the webhook arrive at searchabee? searchabee console → **Sync → Activity**, filter by product ID. Look for a webhook entry matching the change time. - **Webhook arrived, index updated:** go to step 3. - **Webhook arrived, update failed:** the activity row will show the error. Common ones: transient Meilisearch unavailability (auto-retries) or a malformed product (rare). - **No webhook:** Shopify didn't send it. Check Shopify Admin → **Settings → Notifications → Webhooks** to see the delivery log. If Shopify retried and failed, reach out. ## 3. Is the storefront showing cached results? Most themes cache collection pages at the CDN for a short window (typically 60s for Shopify-hosted pages). searchabee's API calls bypass CDN cache for filtered queries, but the initial collection page HTML may still be cached. Shoppers see fresh data within ~60 seconds. For immediate visibility (say, just before a launch), soft-purge the Shopify CDN via a no-op theme save. ## Force resync a single product searchabee console → **Products → [product] → Resync**. This pulls the product directly from Shopify's GraphQL API and upserts into the index, bypassing the webhook path. Use when you suspect a webhook was dropped. ## Force resync the whole index Last resort. **Sync → Rebuild index**. See timings in the [large catalogs guide](/work/searchabee/guides/large-catalogs). During a rebuild, the old index stays serving until the new one is ready — no downtime. ## Monitoring sync health **Sync → Health** surfaces: - Last webhook received (timestamp) - Webhooks last 60m / 24h (volume chart) - Average sync latency p50 / p95 - Queued work (if non-zero, sync is catching up) A flat line on "webhooks last 60m" when your store is active suggests Shopify stopped sending — worth investigating. --- title: Tune search relevance url: https://honeybound.co/work/searchabee/guides/search-config app: searchabee category: operations summary: Searchable fields, synonyms, typo tolerance, and ranking rules. --- searchabee ships with sensible defaults for search relevance. This guide covers the knobs available when you want more control. ## Searchable fields By default, Meilisearch indexes `title`, `description`, `vendor`, `product_type`, and `tags`. Fields appear in ranking priority order — a match on `title` ranks higher than a match on `description`. **Console → Search → Fields**: add or remove searchable fields (e.g., include a specific metafield). ## Synonyms Shoppers search in their words. "Sneakers" and "trainers" and "runners" often mean the same thing. Synonyms map one term to others so all three find the same products. **Console → Search → Synonyms**: list pairs or groups. Example: ``` sneaker ↔ trainer ↔ runner tee ↔ t-shirt ↔ tshirt ``` ## Typo tolerance Meilisearch is typo-tolerant by default (one typo allowed on words ≥5 chars, two typos on words ≥9 chars). This rarely needs adjustment, but you can tighten for brand-name-heavy catalogs (where typos matter) or loosen for long-word catalogs. **Console → Search → Typo tolerance**. ## Stop words Common words that should be ignored in search (e.g., "the", "and", "for"). Defaults are set per-language based on your shop's primary locale. **Console → Search → Stop words**: override the list for your specific catalog. ## Ranking rules Meilisearch's ranking combines: word order, proximity, exactness, attribute priority, and custom ranking. For most merchants, the default order is fine. The one knob worth considering: add a custom ranking on a field like `sales_count` or `rating` so popular/well-reviewed products bubble up when relevance is a tie. **Console → Search → Ranking**: drag to reorder or add custom fields. ## Merchandising rules Pinned results: given a query, force specific products to appear at the top (e.g., searching "sale" pins the sale collection's hero items). These live in **Search → Pinned results** per-query. ## Measuring impact **Search → Analytics** tracks search terms, click-through rate per term, and zero-result queries. Zero-result queries are often where synonyms pay off — shoppers are searching for something you sell but can't find it. --- title: recurrabee v0.1.0 changelog url: https://honeybound.co/work/recurrabee/changelog version: v0.1.0 date: 2026-04-19 --- ### Added - Initial beta release - Subscription contract state machine (active, paused, past-due, cancelled) - Dunning with configurable retry policy - Checkout UI extension for subscriber self-serve - Customer account portal block - Shopify Flow triggers for state transitions - Managed Installation and Token Exchange auth --- title: eventabee v1.0.3 changelog url: https://honeybound.co/work/eventabee/changelog version: v1.0.3 date: 2026-05-18 --- ### Added - AI Commerce readiness reporting now helps merchants spot agent-assisted shopping sessions and orders using privacy-safe attribution signals. ### Improved - Shopify order enrichment gives Eventabee a clearer path from storefront activity to checkout outcomes without exposing customer details in public reporting. --- title: eventabee v1.0.2 changelog url: https://honeybound.co/work/eventabee/changelog version: v1.0.2 date: 2026-05-14 --- ### Improved - External-domain tracking now uses short-lived browser session tokens after domain verification, while preserving compatibility with existing snippets. ### Fixed - Browser SDK event batches are accepted consistently by the ingest API. --- title: eventabee v1.0.1 changelog url: https://honeybound.co/work/eventabee/changelog version: v1.0.1 date: 2026-05-07 --- ### Improved - Merchant lifecycle notifications now include richer Shopify shop profile context, giving support a clearer view of installs, uninstalls, billing plan, region, and onboarding state without exposing merchant details in public analytics. --- title: eventabee v1.0.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v1.0.0 date: 2026-05-07 --- ### Added - Eventabee is now publicly available on the Shopify App Store at apps.shopify.com/eventabee. Any Shopify merchant can install directly, no invite link required. - Public pricing on the listing — Free, Pro ($49/mo), and Business ($199/mo). Every paid tier includes a 7-day free trial. - Shopify-managed billing on every tier. One invoice, one place to cancel or downgrade. ### Improved - Onboarding flow rewritten for self-serve installs: post-install you land on a 4-step setup checklist (theme embed → consent → first destination → verify) with copy-paste verification commands. - Listing-aligned destination matrix on the Connect a destination screen, so the in-app catalog mirrors what merchants saw before installing. - "Beta" framing has been removed across the marketing site, in-app empty states, and FAQ. Eventabee is GA. --- title: eventabee v0.7.2 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.7.2 date: 2026-05-02 --- ### Improved - Storefront-detected experiment_viewed events now carry the same identifier set as other pixel events, so destinations score them on par for event quality. ### Fixed - Events filtered out for reasons other than consent (e.g. a destination that doesn't support a given event type) were mis-badged as "blocked by consent" in the event viewer. They now show as "filtered" with the actual reason. --- title: eventabee v0.7.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.7.0 date: 2026-04-27 --- ### Added - Embedded read-only summary inside Shopify Admin — Performance hero metrics and quick deep-link to the full standalone dashboard. - Click-through DPA at first install. Acceptance is recorded against your shop and DPA version. - "Request a destination" form on every paid tier — submit a vendor and we build the connector for everyone. - Per-token revoke for shareable Impact Report URLs. The admin lists every active share with a Revoke button; revoked URLs return 404 immediately. - Public privacy disclosure guide at honeybound.co with copy-paste templates merchants can drop into their privacy policies. ### Improved - DSAR auto-response is now opt-in and only fires on deterministic identity matches; best-effort matches always queue for manual review. Default is off. - Cross-domain attribution now requires explicit recorded marketing consent. Every event carries an `attribution_method` field visible to destinations and DSAR flows. - Self-serve custom-pixel destinations have been retired in favour of the new request flow. Every destination is a first-party connector with a vendor DPA in place. - Annual pricing remains 20% off monthly billing for Pro and Business. - Meta Event Match Quality (EMQ) is shown as the Meta-returned value; TikTok and Google Ads scores are now labelled "Event Quality" with an inline note that they are eventabee-synthesized from delivery and field-coverage signals. ### Fixed - Trial eligibility is now enforced consistently per shop, so returning merchants see the right paid-plan state after resubscribing. --- title: eventabee v0.6.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.6.0 date: 2026-04-24 --- ### Added - Run eventabee on any domain — headless storefronts, customer portals, marketing sites, multi-region deployments — via a new browser SDK. Business plan. - Per-domain public keys with rotation and revocation. Add and remove domains from the admin without touching storefront code. Business plan. - Server-side cross-domain visitor stitching: known-identity linking, cross-subdomain cookies, URL-linker hash-fragment bridging, and a full 90-day decision audit log. Available on request. - Standalone consent banner that runs on any domain — 6 layouts, geo-targeted opt-in, opt-out, and implied modes, automatic Shopify Customer Privacy API sync where present. Business plan. - External-domain health page: SDK error-rate trends, rejection stream, and a diagnose-a-domain tool to pinpoint misconfigured installs. Business plan. - Schema.org product page auto-detection: the external-domain SDK emits product_viewed events automatically when JSON-LD product data is present, with no merchant code required. - Performance dashboard (Pro and up) showing how much eventabee is moving your ROAS — server-side recovery rate, Event Match Quality uplift since install, and attribution completeness, with an actionable opportunities banner ranked by estimated impact. - Per-filter-reason delivery drill-down with a destination capability matrix: see exactly which destinations dropped which events and why. - Per-destination event quality drill-down with field-presence bars, ranked limiting factors, and cohort-backed impact estimates like "+X EMQ if you bring phone coverage to 80%". Business plan. - Monthly impact report — print-perfect PDF download, 30-day shareable read-only URL, and configurable multi-email auto-distribution so reports land in every stakeholder's inbox. Business plan. - Synthesized Event Match Quality scores for TikTok and Google Ads, alongside the existing Meta EMQ. ### Improved - Event Quality and Recovery moved under the new Performance section at /admin/performance/. Previous URLs 301-redirect for one release cycle. --- title: eventabee v0.5.1 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.5.1 date: 2026-04-24 --- ### Added - Annual billing: Pro at $39/mo (billed annually) and Business at $159/mo (billed annually) — 20% off monthly rates. - 7-day free trial on Pro and Business for first-time paid subscribers. --- title: eventabee v0.5.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.5.0 date: 2026-04-24 --- ### Added - Optimizely is now the fifth auto-detected A/B testing platform, alongside Kameleoon, VWO, Visually A/B, and GTM dataLayer. Experiment context and `experiment_viewed` events forward to all your destinations automatically. - Three-tier pricing: Free · Pro ($49) · Business ($199). No volume caps at any tier — eventabee never charges you for more events or orders. - Business plan: external-domain tracking support for headless storefronts, customer portals, and marketing sites. ### Improved - DSAR and audit export are now generally available on their respective plan tiers (Business and Pro). --- title: eventabee v0.3.4 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.3.4 date: 2026-04-23 --- ### Improved - DSAR review page now shows per-event match detail grouped by confidence level (HIGH / MEDIUM / LOW). Merchants can scan which specific events matched via which predicate before releasing — no need to download the bundle ZIP for routine review. Capped at the first 500 matches; larger DSARs fall back to the bundle's identity_graph.json for the full list. --- title: eventabee v0.3.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.3.0 date: 2026-04-23 --- ### Added - DSAR request fulfillment (Business): generate a tamper-evident bundle of every piece of data eventabee holds on a subject, keyed on email with optional phone or Shopify customer ID. Includes an identity-resolution graph that shows which predicate matched which row — defensible under GDPR Article 15 audit. Async generation, 7-day signed download links, 30-day retention. --- title: eventabee v0.4.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.4.0 date: 2026-04-23 --- ### Added - A/B test capture (Business): automatically detect Kameleoon on your storefront, or any A/B tool pushing to GTM dataLayer. Every event carries active variant context to your destinations. A new experiment_viewed event fires once per session per variant. PostHog receives native $experiment_started events; Segment gets "Experiment Viewed" spec events; Meta and other destinations get the variant context as custom data. - Kameleoon and Visually A/B added to the script-block catalog as analytics-category tools — they're consent-gated automatically. --- title: eventabee v0.3.6 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.3.6 date: 2026-04-23 --- ### Improved - Privacy mode's JSON payload blur is now per-value instead of per-block. You still see the payload structure — keys, types, punctuation — and only the PII values (emails, IPs, phones, names, address fields) blur. Hover any blurred value to reveal. Makes in-product payload debugging readable during recordings. --- title: eventabee v0.4.1 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.4.1 date: 2026-04-23 --- ### Added - VWO and Visually A/B now join Kameleoon as auto-detected A/B testing integrations. Every destination you've connected — Google Ads, TikTok, Pinterest, Snapchat, Klaviyo, Meta, PostHog, Segment, and custom webhooks — receives variant context on every event. - A/B integrations admin page at Configuration → A/B testing: see which tools eventabee is detecting on your storefront, with a per-tool kill switch if you ever need to opt out. --- title: eventabee v0.4.2 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.4.2 date: 2026-04-23 --- ### Improved - Faster A/B testing admin page: dedicated experiments index means the Detected Tools query is instant regardless of event volume. - Destinations that support a single experiment-name field (Meta, Google Ads, TikTok, Pinterest, Snapchat) now receive a pipe-separated list when a visitor is in multiple concurrent experiments. - Recent experiment_viewed events now visible on the A/B integrations admin page. --- title: eventabee v0.3.3 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.3.3 date: 2026-04-23 --- ### Improved - Identity resolution summary card on the review page is expanded by default and explains where per-event match detail lives (the bundle's identity_graph.json). ### Fixed - Releasing a DSAR from the review page now correctly transitions from `awaiting_review` to `released` (previously was rejected as "already released or in invalid state" for webhook-originated requests). - Customer release and refusal emails now show your configured DSAR notification email as the fraud-reporting contact (previously showed a placeholder). - Refuse action now explicitly blocks terminal-state transitions (can't refuse an already-released or expired request). --- title: eventabee v0.3.2 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.3.2 date: 2026-04-23 --- ### Fixed - Merchants now receive eventabee notification emails for DSAR review, auto-release countdown, and SLA reminders. Set your notification email in DSAR Settings. Requires Business plan with DSAR enabled. --- title: eventabee v0.3.1 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.3.1 date: 2026-04-23 --- ### Added - Shopify DSAR webhooks now auto-build a tamper-evident bundle the moment the customer submits. Merchants review, release, or refuse with structured reasons; every decision is recorded in an immutable audit log suitable for compliance defense. - Business merchants can opt into full-auto fulfilment: all-HIGH-confidence identity matches release to the customer after a 24-hour safety window; lower-confidence matches always route to manual review. ### Improved - DSAR identity resolution now tags each match with a confidence level (HIGH / MEDIUM / LOW), surfaced in-product and in the bundle's identity_graph.json. --- title: eventabee v0.3.5 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.3.5 date: 2026-04-22 --- ### Added - Privacy mode: a sidebar toggle blurs customer emails, IPs, phone numbers, and identifiers across the entire admin UI. Hover or keyboard-focus any blurred field to reveal its contents. Persists per-browser. Designed for safe screen recordings and demos — enable it before you hit record, everything sensitive stays masked until you deliberately hover. --- title: eventabee v0.2.8 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.8 date: 2026-04-22 --- ### Added - Consent receipts now look up by email (Business). DSAR response path: a merchant can paste a customer's email and get that visitor's consent timeline across every device they've used. Forward-only: receipts created before this release can still be looked up by visitor hash. --- title: eventabee v0.2.7 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.7 date: 2026-04-22 --- ### Improved - Consent receipts page now renders per-visitor receipts as a chronological timeline with per-category change highlights, making it easy to see at a glance how a visitor's consent evolved over time. --- title: eventabee v0.2.6 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.6 date: 2026-04-21 --- ### Added - Global Privacy Control: in regions where it's legally required, the banner now automatically respects a visitor's GPC signal. Configurable per shop. - Audit export (Pro and Business): download a tamper-evident bundle of your consent receipts, analytics, script decisions, and cookie records — ready to hand to counsel or a regulator. --- title: eventabee v0.2.5 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.5 date: 2026-04-21 --- ### Added - Cookie scanner (Business): automatically detects the cookies, localStorage keys, and sessionStorage keys your site drops, grouped by the script that set them. Publish a live cookie declaration on your policy page with one line of theme code. --- title: eventabee v0.2.3 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.3 date: 2026-04-21 --- ### Improved - Aggressive mode (Business) now blocks hardcoded trackers in your theme, not just scripts our observer catches after they load. Toggle it on from the Scripts page. --- title: eventabee v0.2.2 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.2 date: 2026-04-21 --- ### Added - Script enforcement log: every allow/block decision is recorded with its consent context and surfaced in a new Activity tab on the Scripts page, plus a per-script "Recent decisions" drawer. Retained 30 days on Pro, 180 days on Business. --- title: eventabee v0.2.1 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.1 date: 2026-04-21 --- ### Improved - Consent banner loads earlier in `` for more reliable script gating. ### Fixed - Migrating a hardcoded script now correctly clears the "Hardcoded" badge. --- title: eventabee v0.2.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.2.0 date: 2026-04-20 --- ### Added - Consent script control: discover and classify third-party scripts running on your storefront; block them until consent is given. --- title: eventabee v0.1.0 changelog url: https://honeybound.co/work/eventabee/changelog version: v0.1.0 date: 2026-04-19 --- ### Added - Initial beta release - Server-side event capture from Web Pixel - Geo-aware consent banner (Theme App Embed) - Meta, Google, TikTok, Klaviyo, Pinterest, Snapchat, Segment, PostHog, generic webhook, and custom destinations - 30-day consent backfill - Per-destination retry and dead-letter queue --- title: searchabee v0.5.0 changelog url: https://honeybound.co/work/searchabee/changelog version: v0.5.0 date: 2026-05-03 --- ### Added - New top-nav app shell — settings is one long page instead of a canvas + drawer - Live storefront preview as a sticky companion rail with mobile/tablet/desktop toggle - Expand the preview to 1:1 in any device width - "On this page" jump-list for fast navigation between sections ### Improved - Whole admin re-anchored in honeybound's brand (warm cream + honey accent, Pangram Sans) - Five focused settings sections instead of seven overlapping ones - One path to every field (the inspector + globals drawer split is gone) - Small screens now collapse the preview into a clean "Show preview" button ### Fixed - Save bar dropping edits across multiple subforms in the same section --- title: searchabee v0.4.1 changelog url: https://honeybound.co/work/searchabee/changelog version: v0.4.1 date: 2026-05-03 --- ### Improved - Globals drawer now slides in instead of snapping - Cleaner panel stacking — opening "More options" closes the inspector instead of layering it underneath - Discard now confirms before throwing away unsaved changes - Browser warns before you navigate away with unsaved settings ### Fixed - Save bar silently dropped failed saves; now flags the failed sections and keeps them dirty so you can retry - Demo catalog fallback no longer flashes the filter tree off-screen during fresh-install backfill --- title: searchabee v0.4.0 changelog url: https://honeybound.co/work/searchabee/changelog version: v0.4.0 date: 2026-05-01 --- ### Added - Direct-manipulation editing — click any element on the preview to edit just the settings that affect it - Global settings drawer (⚙) for non-visual config like currency, custom CSS, and search behavior - Demo product set on the preview during fresh-install catalog sync, so the canvas is never empty ### Improved - Settings preview now renders inside the admin instead of through an iframe — works on every store, including pre-launch ones with password protection - Preview updates instantly while you edit - Filter-tree edits (add option, reorder values, etc.) now refresh the preview live ### Fixed - Preview blocked on stores with storefront password protection - Save button stayed dead after some edits - Filter-tree preview wasn't reacting to CRUD changes --- title: searchabee v0.3.0 changelog url: https://honeybound.co/work/searchabee/changelog version: v0.3.0 date: 2026-04-24 --- ### Added - Live storefront preview on the settings page — see edits in the actual store before saving - Live preview on the filter trees editor too - Auto-detects your theme's colors, fonts, and shape on install - "Re-scan theme" button to pick up theme changes after install - Curated explanations for non-obvious settings ### Improved - Settings page redesigned with a collapsible side panel and no layout jump - Save without losing your scroll position; multi-section saves run in parallel - Badges editor is now inline in settings (one less page to click into) ### Fixed - The old floating preview panel that overlapped form inputs --- title: searchabee v0.2.0 changelog url: https://honeybound.co/work/searchabee/changelog version: v0.2.0 date: 2026-04-23 --- ### Added - Opt-in takeover of the theme's native search bar with a multi-section autocomplete dropdown - Takeover of the /search results page with filter-powered results - Autocomplete now includes matching collections and tags alongside products - Recent searches list for returning shoppers - Keyboard-shortcut hint and loading skeletons in the dropdown - Usage analytics for search autocomplete interactions ### Improved - Suggest endpoint returns results grouped by type in a single call --- title: searchabee v0.1.1 changelog url: https://honeybound.co/work/searchabee/changelog version: v0.1.1 date: 2026-04-19 --- ### Added - Plans page now surfaces subscription status and upgrade prompts - Storefront widget hides gracefully if the app has been uninstalled ### Improved - Privacy policy clarifies hosting region and sub-processor handling - Terms include governing-law and termination clauses ### Fixed - Billing fields are cleared on uninstall for a cleaner audit trail - Declining a charge now flashes a confirmation instead of silently returning --- title: searchabee v0.1.0 changelog url: https://honeybound.co/work/searchabee/changelog version: v0.1.0 date: 2026-04-19 --- ### Added - Initial beta release - Per-shop Meilisearch indexes with webhook-driven sync - Merchant-defined filter trees bound per collection template - Four filter source types: product options, product fields, variant fields, category metafields - Theme App Extension block for storefront rendering - Managed Installation and Token Exchange auth