{"id":7331,"date":"2026-03-24T08:48:54","date_gmt":"2026-03-24T08:48:54","guid":{"rendered":"https:\/\/www.wizbrand.com\/tutorials\/self-referral-exclusion\/"},"modified":"2026-03-24T08:48:54","modified_gmt":"2026-03-24T08:48:54","slug":"self-referral-exclusion","status":"publish","type":"post","link":"https:\/\/www.wizbrand.com\/tutorials\/self-referral-exclusion\/","title":{"rendered":"Self-referral Exclusion: What It Is, Key Features, Benefits, Use Cases, and How It Fits in Tracking"},"content":{"rendered":"\n

Self-referral Exclusion is a measurement safeguard that prevents your own domains (or systems you control) from incorrectly showing up as the \u201creferring source\u201d that drove a visit or conversion. In Conversion & Measurement<\/strong>, it\u2019s one of the most important protections against polluted attribution\u2014especially when checkout flows, payment providers, subdomains, or cross-domain journeys are involved.<\/p>\n\n\n\n

In practical Tracking<\/strong>, self-referrals often appear when analytics can\u2019t recognize a user as the same session across steps. That usually happens because cookies are reset, parameters are lost, redirects occur, or a journey crosses to another domain and back. A well-designed Self-referral Exclusion<\/strong> approach helps ensure conversions are credited to the real marketing source (paid, organic, email, partner, etc.), not to your own website.<\/p>\n\n\n\n

Modern Conversion & Measurement<\/strong> strategies depend on clean source\/medium data, consistent sessions, and trustworthy funnel reporting. Without Self-referral Exclusion, teams can make confident-looking decisions based on incorrect attribution\u2014leading to budget waste, broken performance narratives, and unnecessary technical churn.<\/p>\n\n\n\n

What Is Self-referral Exclusion?<\/h2>\n\n\n\n

Self-referral Exclusion<\/strong> is the practice of configuring your analytics and measurement setup so that visits originating from your own domains (or specific internal domains) do not overwrite the original traffic source for a user journey. It is not about hiding traffic; it\u2019s about maintaining correct attribution across multi-step experiences.<\/p>\n\n\n\n

At its core, the concept addresses a simple issue: if analytics believes a user \u201ccame from\u201d your own site (or a related domain), it may start a new session and assign a new referrer\u2014your domain\u2014right before the conversion. That breaks the marketing story.<\/p>\n\n\n\n

From a business perspective, Self-referral Exclusion protects the integrity of Conversion & Measurement<\/strong> reporting: campaign ROI, channel performance, assisted conversion analysis, and funnel drop-off diagnostics. Within Tracking<\/strong>, it sits alongside cross-domain measurement, session continuity, consent handling, and tagging governance as a foundational control that keeps data believable.<\/p>\n\n\n\n

Why Self-referral Exclusion Matters in Conversion & Measurement<\/h2>\n\n\n\n

Self-referrals are more than a reporting annoyance\u2014they can reshape decisions. When your own domain becomes a top \u201creferrer,\u201d it can push real channels down in attribution reports and cause teams to underinvest in what actually works.<\/p>\n\n\n\n

Self-referral Exclusion matters because it:<\/p>\n\n\n\n

    \n
  • Preserves marketing attribution<\/strong> by preventing the conversion touchpoint from being reassigned to your site.<\/li>\n
  • Improves decision accuracy<\/strong> in Conversion & Measurement<\/strong>, especially for budget allocation and channel strategy.<\/li>\n
  • Reduces false funnel breakpoints<\/strong> where analytics claims users \u201cre-entered\u201d the site from itself.<\/li>\n
  • Protects experimentation and optimization<\/strong> by ensuring A\/B test results and landing page performance aren\u2019t skewed by session resets.<\/li>\n<\/ul>\n\n\n\n

    Organizations that take Self-referral Exclusion seriously often gain a competitive advantage: they can see clearer signals sooner, adjust spend more confidently, and diagnose UX or checkout issues without data distortion.<\/p>\n\n\n\n

    How Self-referral Exclusion Works<\/h2>\n\n\n\n

    Self-referral Exclusion is partly configuration and partly good measurement architecture. Here\u2019s how it works in practice within Tracking<\/strong> and Conversion & Measurement<\/strong>:<\/p>\n\n\n\n

      \n
    1. \n

      Trigger: A journey that risks session breaks<\/strong>\n A user lands from a campaign, browses, then hits a step that changes domains or introduces redirects (checkout, SSO login, payment, booking engine, embedded app, support portal).<\/p>\n<\/li>\n

    2. \n

      Processing: Analytics evaluates session and referrer<\/strong>\n If analytics can\u2019t read the existing client\/session identifiers (often cookie-related) or considers the user \u201cnew,\u201d it starts a new session and reads the referrer from the browser. If that referrer is your own domain, you get a self-referral.<\/p>\n<\/li>\n

    3. \n

      Execution: Exclusion rules and domain logic prevent overwrite<\/strong>\n With Self-referral Exclusion, you configure measurement rules so your own domains (and sometimes specific third-party domains involved in the flow) do not replace the original campaign source. In parallel, you often implement cross-domain measurement and consistent tagging so the same user\/session is recognized across steps.<\/p>\n<\/li>\n

    4. \n

      Outcome: Cleaner attribution and stable sessions<\/strong>\n Reports reflect the real acquisition source, conversion paths remain coherent, and Conversion & Measurement<\/strong> outputs (ROAS, CAC, channel contribution) become more trustworthy.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

      A key nuance: Self-referral Exclusion can prevent the obvious symptom (self-referral attribution), but it doesn\u2019t automatically fix the underlying cause (session fragmentation). For reliable Tracking<\/strong>, you typically need both correct exclusions and correct session continuity.<\/p>\n\n\n\n

      Key Components of Self-referral Exclusion<\/h2>\n\n\n\n

      Effective Self-referral Exclusion is a blend of configuration, instrumentation, and governance. Core components include:<\/p>\n\n\n\n

      Domain and journey mapping<\/h3>\n\n\n\n

      You need a clear inventory of all domains and subdomains involved in the customer journey\u2014marketing site, app domain, checkout domain, help center, account portal, and any \u201cintermediate\u201d systems.<\/p>\n\n\n\n

      Cross-domain and session continuity setup<\/h3>\n\n\n\n

      Self-referrals often indicate cross-domain measurement gaps. Consistent client identifiers, linker parameters (where applicable), and aligned cookie settings reduce session resets that create self-referrals in the first place.<\/p>\n\n\n\n

      Tagging and redirect hygiene<\/h3>\n\n\n\n

      Redirect chains, URL shorteners, mixed http\/https, or inconsistent campaign parameters can strip attribution. Tagging governance ensures UTM parameters, click IDs, and referrer context are preserved.<\/p>\n\n\n\n

      Consent and privacy controls<\/h3>\n\n\n\n

      Consent banners and privacy settings can affect cookies and storage, changing session behavior. In Conversion & Measurement<\/strong>, you must design Self-referral Exclusion to work within consent-driven Tracking<\/strong> models.<\/p>\n\n\n\n

      Team responsibilities and change management<\/h3>\n\n\n\n

      Self-referral Exclusion touches marketing, analytics, web development, and sometimes payments or product teams. Clear ownership prevents \u201csilent regressions\u201d after site releases or vendor changes.<\/p>\n\n\n\n

      Types of Self-referral Exclusion<\/h2>\n\n\n\n

      \u201cTypes\u201d aren\u2019t always formalized, but there are practical contexts where Self-referral Exclusion differs:<\/p>\n\n\n\n

      1) First-party domain self-referrals<\/h3>\n\n\n\n

      Your primary site appears as a referral source, usually due to session resets between pages or subdomains. This is the classic Self-referral Exclusion case.<\/p>\n\n\n\n

      2) Cross-domain journey exclusions<\/h3>\n\n\n\n

      Common when the conversion happens on a different domain (store, booking, app, checkout) and the user returns to a confirmation page on the main domain. Proper cross-domain measurement plus Self-referral Exclusion prevents the confirmation step from being attributed to your own domain.<\/p>\n\n\n\n

      3) Third-party flow exclusions (payment\/identity\/embedded)<\/h3>\n\n\n\n

      Some journeys involve external providers (payments, authentication, booking engines). While not \u201cself\u201d domains, these can behave similarly by overwriting attribution late in the funnel. Teams often treat them similarly in Conversion & Measurement<\/strong> planning\u2014carefully excluding or managing them so the original source remains intact.<\/p>\n\n\n\n

      Real-World Examples of Self-referral Exclusion<\/h2>\n\n\n\n

      Example 1: Ecommerce checkout on a separate domain<\/h3>\n\n\n\n

      A retailer runs paid social campaigns to product pages on www.brand.com<\/code>, but checkout happens on checkout.brand-payments.com<\/code>. Users return to www.brand.com\/thank-you<\/code>. Without Self-referral Exclusion and cross-domain Tracking<\/strong>, the thank-you page starts a new session and attributes the purchase to checkout.brand-payments.com<\/code> or www.brand.com<\/code> as a referrer. With Self-referral Exclusion (and proper cross-domain setup), the purchase remains credited to paid social in Conversion & Measurement<\/strong> reports.<\/p>\n\n\n\n

      Example 2: SaaS trial sign-up with SSO login redirects<\/h3>\n\n\n\n

      A SaaS company uses an identity system on login.brand.com<\/code> that redirects back to the app. If the identity flow drops campaign parameters or breaks session continuity, analytics may report login.brand.com<\/code> as the referrer for sign-ups. Implementing Self-referral Exclusion plus consistent tagging ensures the original acquisition channel (organic search, email, partner) is preserved for accurate Conversion & Measurement<\/strong>.<\/p>\n\n\n\n

      Example 3: Multi-subdomain content + app experience<\/h3>\n\n\n\n

      A publisher drives traffic to learn.brand.com<\/code> and then sends users into a subscription app on app.brand.com<\/code>. Without aligned cookie and cross-subdomain Tracking<\/strong>, subscriptions can appear as referrals from learn.brand.com<\/code> to app.brand.com<\/code>, inflating \u201creferral\u201d as a channel. Self-referral Exclusion clarifies the true acquisition source while teams fix the underlying session continuity.<\/p>\n\n\n\n

      Benefits of Using Self-referral Exclusion<\/h2>\n\n\n\n

      When implemented thoughtfully, Self-referral Exclusion produces measurable improvements:<\/p>\n\n\n\n

        \n
      • More accurate attribution<\/strong> for campaigns, channels, and landing pages in Conversion & Measurement<\/strong>.<\/li>\n
      • Better ROAS and CAC analysis<\/strong> because conversions aren\u2019t mistakenly credited to \u201creferral: yourdomain.com.\u201d<\/li>\n
      • Fewer reporting false alarms<\/strong>, such as sudden \u201creferral spikes\u201d caused by a tagging change or checkout update.<\/li>\n
      • Cleaner funnel analysis<\/strong> with fewer artificial session breaks and fewer \u201cnew users\u201d created by technical issues.<\/li>\n
      • More reliable audience and remarketing signals<\/strong> where analytics feeds downstream systems (within privacy constraints).<\/li>\n
      • Improved customer experience diagnostics<\/strong>, because teams can separate genuine UX drop-offs from measurement artifacts.<\/li>\n<\/ul>\n\n\n\n

        Challenges of Self-referral Exclusion<\/h2>\n\n\n\n

        Self-referral Exclusion is deceptively simple, but several pitfalls are common:<\/p>\n\n\n\n

        Technical causes can be layered<\/h3>\n\n\n\n

        A self-referral may be caused by cookie scoping, redirect behavior, cross-domain gaps, ITP-related constraints, consent mode behavior, or a tag firing sequence issue. Excluding the domain may hide symptoms while the root cause persists.<\/p>\n\n\n\n

        Over-excluding can mask real problems<\/h3>\n\n\n\n

        If you broadly exclude too many domains, you may hide legitimate referral relationships (for example, a true partner referral hosted on a related domain). In Tracking<\/strong>, precision matters.<\/p>\n\n\n\n

        Complex ecosystems change frequently<\/h3>\n\n\n\n

        Checkout providers, SSO systems, CMS migrations, and app routing updates can reintroduce self-referrals. Self-referral Exclusion requires ongoing governance.<\/p>\n\n\n\n

        Attribution models can still differ<\/h3>\n\n\n\n

        Even with Self-referral Exclusion, different attribution views (last-click vs. data-driven, event-scoped vs. session-scoped) can produce different answers. Conversion & Measurement<\/strong> teams should align stakeholders on which reports are \u201csource of truth.\u201d<\/p>\n\n\n\n

        Best Practices for Self-referral Exclusion<\/h2>\n\n\n\n

        Use these practices to keep Self-referral Exclusion effective and audit-ready:<\/p>\n\n\n\n

          \n
        1. \n

          Start with a self-referral audit<\/strong>\n – Review referral reports for your own domains and subdomains.\n – Identify where self-referrals occur (entry pages, confirmation pages, specific devices\/browsers).<\/p>\n<\/li>\n

        2. \n

          Map the end-to-end user journey<\/strong>\n – Document domain hops, redirects, iframes, payment steps, and login flows.\n – Note which step triggers the session break.<\/p>\n<\/li>\n

        3. \n

          Fix session continuity, not just attribution symptoms<\/strong>\n – Implement cross-domain measurement where needed.\n – Standardize cookie settings across subdomains when appropriate.\n – Ensure campaign parameters and click IDs are preserved through redirects.<\/p>\n<\/li>\n

        4. \n

          Use exclusion lists carefully<\/strong>\n – Exclude only domains you control (and specific necessary third-party flow domains) that are known to overwrite attribution.\n – Avoid blanket exclusions that could hide meaningful referrers.<\/p>\n<\/li>\n

        5. \n

          Validate with controlled tests<\/strong>\n – Run test journeys from known UTMs (or test campaigns).\n – Confirm that the conversion retains the original source through the entire funnel.<\/p>\n<\/li>\n

        6. \n

          Monitor after releases<\/strong>\n – Add checks to QA for tagging and redirects.\n – In Conversion & Measurement<\/strong> reporting, alert on sudden increases in self-referrals or session restarts.<\/p>\n<\/li>\n

        7. \n

          Document and assign ownership<\/strong>\n – Maintain a measurement spec: domains included, excluded, and why.\n – Assign owners for Tracking<\/strong> changes across web, product, and marketing ops.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

          Tools Used for Self-referral Exclusion<\/h2>\n\n\n\n

          Self-referral Exclusion is typically managed through a stack rather than a single tool. Common tool categories include:<\/p>\n\n\n\n

            \n
          • Analytics tools<\/strong>: Configure referral exclusions, cross-domain measurement rules, session settings, and attribution reporting. These tools are the center of Conversion & Measurement<\/strong> governance.<\/li>\n
          • Tag management systems<\/strong>: Control tag firing, linker parameters (when applicable), and consistent event instrumentation across domains for stable Tracking<\/strong>.<\/li>\n
          • Consent management platforms<\/strong>: Influence cookie availability and storage behavior, affecting session continuity and self-referral risk.<\/li>\n
          • Ad platforms and campaign systems<\/strong>: Require consistent tagging (UTMs, click IDs) and correct final URLs to preserve attribution through redirects.<\/li>\n
          • CRM and marketing automation<\/strong>: Depend on clean source data for lead attribution, lifecycle reporting, and downstream segmentation.<\/li>\n
          • Data warehouses and BI dashboards<\/strong>: Useful for anomaly detection (self-referral spikes), multi-touch modeling, and reconciliations between analytics and backend orders.<\/li>\n<\/ul>\n\n\n\n

            The most important \u201ctool\u201d is often your measurement process: change control, QA checklists, and a consistent approach to Tracking<\/strong> across teams.<\/p>\n\n\n\n

            Metrics Related to Self-referral Exclusion<\/h2>\n\n\n\n

            You can\u2019t manage Self-referral Exclusion without measurable indicators. Useful metrics include:<\/p>\n\n\n\n

              \n
            • Self-referral rate<\/strong>: Percentage of sessions (or conversions) where the referrer matches your own domain(s). Trend this over time and by device\/browser.<\/li>\n
            • Attribution stability<\/strong>: Share of conversions attributed to \u201cdirect\u201d or \u201creferral\u201d that changes after site releases can indicate broken Tracking<\/strong>.<\/li>\n
            • Session break indicators<\/strong>: Sudden rises in sessions per user, new users, or short sessions around checkout\/login steps.<\/li>\n
            • Conversion rate by source\/medium<\/strong>: Watch for unnatural drops in key channels when self-referrals appear.<\/li>\n
            • Checkout\/confirmation page entry rate<\/strong>: High direct entries to confirmation pages can signal session resets or tagging problems.<\/li>\n
            • Order\/lead reconciliation<\/strong>: Compare analytics conversions to backend transactions; widening gaps can be related to measurement issues, including self-referrals.<\/li>\n<\/ul>\n\n\n\n

              In Conversion & Measurement<\/strong>, these metrics help you distinguish real performance shifts from instrumentation drift.<\/p>\n\n\n\n

              Future Trends of Self-referral Exclusion<\/h2>\n\n\n\n

              Self-referral Exclusion will remain essential, but how teams implement it is evolving:<\/p>\n\n\n\n

                \n
              • Privacy and browser changes<\/strong>: Increased restrictions on cookies and storage can create more session fragmentation, making robust Tracking<\/strong> design and exclusion governance more important.<\/li>\n
              • First-party data strategies<\/strong>: More organizations are investing in server-side collection, identity resolution, and event pipelines. These can reduce self-referrals by stabilizing identifiers\u2014while introducing new configuration complexity.<\/li>\n
              • Automation and anomaly detection<\/strong>: AI-assisted monitoring will increasingly flag self-referral spikes, redirect loops, and attribution anomalies within Conversion & Measurement<\/strong> dashboards.<\/li>\n
              • More complex customer journeys<\/strong>: Apps, embedded experiences, headless commerce, and multi-domain architectures will increase the need for precise domain mapping and ongoing Self-referral Exclusion maintenance.<\/li>\n<\/ul>\n\n\n\n

                The long-term direction is clear: stronger measurement governance, more automated QA, and tighter alignment between marketing and engineering to keep Tracking<\/strong> reliable.<\/p>\n\n\n\n

                Self-referral Exclusion vs Related Terms<\/h2>\n\n\n\n

                Self-referral Exclusion vs cross-domain tracking<\/h3>\n\n\n\n

                Cross-domain tracking is the mechanism to recognize a user across domains and keep the same session identity. Self-referral Exclusion<\/strong> is the safeguard that prevents your domain from overwriting attribution when that recognition fails or when the journey returns to your site. In Conversion & Measurement<\/strong>, you often need both: cross-domain continuity to prevent session breaks, and exclusions to prevent attribution hijacks.<\/p>\n\n\n\n

                Self-referral Exclusion vs referral exclusion (general)<\/h3>\n\n\n\n

                Referral exclusion is a broader concept: you exclude specific referrers (sometimes third-party domains) from being counted as referrals. Self-referral Exclusion is a specific subset focused on your own domains and properties. Both affect Tracking<\/strong> attribution, but self-referrals are usually a sign of measurement architecture issues.<\/p>\n\n\n\n

                Self-referral Exclusion vs direct traffic<\/h3>\n\n\n\n

                Direct traffic is typically used when no referrer or campaign source is detected. Self-referrals are the opposite: a referrer is detected, but it\u2019s your own site, which is rarely meaningful for acquisition analysis. Fixing Self-referral Exclusion often reduces fake referral attribution and can also reduce \u201cmysterious direct\u201d conversions caused by session resets.<\/p>\n\n\n\n

                Who Should Learn Self-referral Exclusion<\/h2>\n\n\n\n
                  \n
                • Marketers<\/strong> need Self-referral Exclusion to trust channel performance, optimize campaigns, and defend budget decisions with credible Conversion & Measurement<\/strong> data.<\/li>\n
                • Analysts<\/strong> rely on it to maintain clean datasets, interpret attribution shifts, and produce reliable reporting in complex Tracking<\/strong> environments.<\/li>\n
                • Agencies<\/strong> benefit because clean attribution prevents misdiagnosis (e.g., blaming a channel for a conversion drop that is really a measurement break).<\/li>\n
                • Business owners and founders<\/strong> should understand it to interpret dashboards correctly and avoid funding decisions based on misleading \u201creferral\u201d conversions.<\/li>\n
                • Developers and product teams<\/strong> influence the causes\u2014redirects, domains, checkout flows, consent implementations\u2014so their awareness is critical for durable Tracking<\/strong>.<\/li>\n<\/ul>\n\n\n\n

                  Summary of Self-referral Exclusion<\/h2>\n\n\n\n

                  Self-referral Exclusion prevents your own domains from incorrectly taking credit as the referrer during a customer journey. It matters because it protects attribution integrity, improves reporting accuracy, and supports confident decision-making in Conversion & Measurement<\/strong>. Implemented alongside cross-domain continuity and solid tagging governance, Self-referral Exclusion strengthens Tracking<\/strong> by keeping sessions coherent and ensuring conversions are credited to the true marketing source.<\/p>\n\n\n\n

                  Frequently Asked Questions (FAQ)<\/h2>\n\n\n\n

                  1) What is Self-referral Exclusion in simple terms?<\/h3>\n\n\n\n

                  Self-referral Exclusion is a configuration and measurement practice that stops your own domain(s) from appearing as the referring source that \u201cdrove\u201d a user right before they convert, preserving the original acquisition source.<\/p>\n\n\n\n

                  2) Why do I see my own website as a top referral source?<\/h3>\n\n\n\n

                  This usually happens when sessions break during checkout, login, or cross-domain steps. Analytics starts a new session and reads the browser referrer, which ends up being your own domain.<\/p>\n\n\n\n

                  3) Does Self-referral Exclusion fix broken sessions?<\/h3>\n\n\n\n

                  Not always. Self-referral Exclusion can prevent attribution from being overwritten, but you may still have session fragmentation. For robust Tracking<\/strong>, you often need cross-domain continuity, consistent cookie settings, and redirect hygiene too.<\/p>\n\n\n\n

                  4) How do I know if self-referrals are hurting my Conversion & Measurement reports?<\/h3>\n\n\n\n

                  Look for increases in referrals from your own domains, sudden drops in paid\/organic attribution, spikes in \u201cdirect\u201d conversions, and unusual session increases per user\u2014especially around conversion steps.<\/p>\n\n\n\n

                  5) What\u2019s the difference between Self-referral Exclusion and excluding a payment provider?<\/h3>\n\n\n\n

                  Self-referral Exclusion focuses on your own domains. Excluding a payment provider is a similar tactic used when a third-party flow overwrites attribution. Both should be applied carefully so you don\u2019t hide meaningful referrers or mask root causes.<\/p>\n\n\n\n

                  6) Which teams should own Self-referral Exclusion and Tracking governance?<\/h3>\n\n\n\n

                  Ownership is usually shared: analytics\/marketing ops manage configuration, developers manage domains\/redirects, and marketing teams validate Conversion & Measurement<\/strong> outcomes. Clear change control prevents regressions.<\/p>\n\n\n\n

                  7) What should I monitor after implementing Self-referral Exclusion?<\/h3>\n\n\n\n

                  Monitor self-referral rates, conversion attribution by channel, session stability around checkout\/login, and reconciliation against backend conversions. Also review changes after releases, consent updates, or domain migrations.<\/p>\n","protected":false},"excerpt":{"rendered":"

                  Self-referral Exclusion is a measurement safeguard that prevents your own domains (or systems you control) from incorrectly showing up as the \u201creferring source\u201d that drove a visit or conversion. In **Conversion & Measurement**, it\u2019s one of the most important protections against polluted attribution\u2014especially when checkout flows, payment providers, subdomains, or cross-domain journeys are involved.<\/p>\n","protected":false},"author":10235,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1890],"tags":[],"class_list":["post-7331","post","type-post","status-publish","format-standard","hentry","category-tracking"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/7331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/users\/10235"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/comments?post=7331"}],"version-history":[{"count":0,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/7331\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/media?parent=7331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/categories?post=7331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/tags?post=7331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}