{"id":11563,"date":"2026-04-02T02:44:51","date_gmt":"2026-04-02T02:44:51","guid":{"rendered":"https:\/\/www.wizbrand.com\/tutorials\/protected-audience-api\/"},"modified":"2026-04-02T02:44:51","modified_gmt":"2026-04-02T02:44:51","slug":"protected-audience-api","status":"publish","type":"post","link":"https:\/\/www.wizbrand.com\/tutorials\/protected-audience-api\/","title":{"rendered":"Protected Audience API: What It Is, Key Features, Benefits, Use Cases, and How It Fits in Privacy & Consent"},"content":{"rendered":"\n

Modern advertising is being rebuilt around user choice, data minimization, and safer ways to reach relevant audiences. Protected Audience API<\/strong> is one of the most important concepts in that shift: it enables interest-based and remarketing-style advertising without relying on third-party cookies or exposing a person\u2019s browsing history to multiple intermediaries.<\/p>\n\n\n\n

In a Privacy & Consent<\/strong> program, the goal isn\u2019t only to collect consent\u2014it\u2019s to design marketing and measurement so they still work when identifiers are limited. Protected Audience API<\/strong> matters because it moves key parts of ad targeting and selection into the browser environment, reducing the amount of user-level data that leaves the device while still supporting common marketing outcomes like re-engagement, frequency control, and performance optimization. Done well, it becomes a cornerstone of privacy-respecting digital marketing strategy.<\/p>\n\n\n\n

What Is Protected Audience API?<\/h2>\n\n\n\n

Protected Audience API<\/strong> is a browser-based advertising technology designed to support interest-based advertising (especially remarketing) in a more privacy-preserving way. Instead of third-party cookies letting many parties observe a person across sites, the browser can store a limited, user-associated \u201caudience membership\u201d (often based on first-party interactions) and run an ad selection process locally.<\/p>\n\n\n\n

The core concept is simple: ad decisions can be made without sharing a person\u2019s identity or full browsing behavior with every participant in the ad ecosystem<\/strong>. Advertisers can define audiences based on their own site\/app interactions, and the browser helps select an ad when that person later visits other sites that show ads.<\/p>\n\n\n\n

From a business perspective, Protected Audience API<\/strong> aims to preserve valuable performance marketing use cases\u2014like cart-abandoner retargeting or reactivation campaigns\u2014while aligning with stricter expectations around Privacy & Consent<\/strong> and reduced cross-site tracking.<\/p>\n\n\n\n

Within Privacy & Consent<\/strong>, this concept sits at the intersection of:\n– user transparency and control (what audiences exist and how they\u2019re used),\n– data minimization (less data shared outside the device),\n– governance (policies for audience creation and retention), and\n– measurement adaptation (how you evaluate performance when signals change).<\/p>\n\n\n\n

Why Protected Audience API Matters in Privacy & Consent<\/h2>\n\n\n\n

As browsers and regulators push the market away from pervasive tracking, marketers need alternatives that keep campaigns effective without undermining user trust. Protected Audience API<\/strong> matters strategically because it supports a realistic middle ground: advertising can remain relevant, but with stronger boundaries on data sharing.<\/p>\n\n\n\n

Key sources of business value include:\n– Resilience<\/strong>: performance programs can continue as third-party cookies diminish.\n– Trust-building<\/strong>: privacy-preserving approaches reduce \u201ccreepiness\u201d and improve brand perception.\n– Better alignment with governance<\/strong>: the system design can reduce accidental leakage of sensitive data to many vendors.\n– Competitive advantage<\/strong>: teams that operationalize privacy-safe audience strategies earlier often maintain more stable acquisition and re-engagement costs during industry transitions.<\/p>\n\n\n\n

In Privacy & Consent<\/strong> planning, it\u2019s not enough to say \u201cwe comply.\u201d You also need workable activation patterns that respect consent choices and still deliver outcomes. Protected Audience API<\/strong> is one of those patterns.<\/p>\n\n\n\n

How Protected Audience API Works<\/h2>\n\n\n\n

While implementations vary by browser and ecosystem, Protected Audience API<\/strong> is typically understood through this practical workflow:<\/p>\n\n\n\n

    \n
  1. \n

    Input \/ trigger (audience creation)<\/strong>\n – A person visits an advertiser\u2019s site or uses an app and takes an action (viewed product, started checkout, subscribed, etc.).\n – Based on configured rules\u2014and consistent with consent choices\u2014the browser can associate that person with an advertiser-defined audience (often called an \u201cinterest group\u201d in technical discussions).<\/p>\n<\/li>\n

  2. \n

    Processing (on-device storage and rules)<\/strong>\n – Audience membership and related metadata are stored in a protected browser context rather than as a broadly readable third-party identifier.\n – Rules like membership duration, caps, and creative eligibility can be applied to reduce over-targeting and limit data retention.<\/p>\n<\/li>\n

  3. \n

    Execution \/ application (ad selection)<\/strong>\n – When the person later visits a publisher site that supports this approach, the browser can run an ad selection process that considers eligible audiences and ad candidates.\n – The selection logic is designed to keep sensitive user-level details from being widely shared across ad-tech parties.<\/p>\n<\/li>\n

  4. \n

    Output \/ outcome (ad shown + limited reporting)<\/strong>\n – The winning ad is rendered, and reporting is generally designed to be more privacy-preserving than traditional user-level logs.\n – Marketers still evaluate performance, but measurement often relies more on aggregated signals, modeled results, or privacy-safe reporting constraints.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

    This is why Protected Audience API<\/strong> is often described as \u201con-device\u201d or \u201cin-browser\u201d audience-based advertising: the browser plays an active role in protecting user data while enabling ad relevance.<\/p>\n\n\n\n

    Key Components of Protected Audience API<\/h2>\n\n\n\n

    To use Protected Audience API<\/strong> effectively, teams typically coordinate across marketing, engineering, and governance. The major components include:<\/p>\n\n\n\n

      \n
    • First-party audience definitions<\/strong><\/li>\n
    • Clear rules for what actions qualify a user for an audience (e.g., \u201cviewed SKU,\u201d \u201cadded to cart,\u201d \u201clead form started\u201d).<\/li>\n
    • \n

      Policies to avoid sensitive categories and to keep audience logic explainable.<\/p>\n<\/li>\n

    • \n

      Consent-aware tagging and event collection<\/strong><\/p>\n<\/li>\n

    • A setup that respects consent states before placing users into audiences.<\/li>\n
    • \n

      Strong coordination between your consent layer and activation logic, central to Privacy & Consent<\/strong> operations.<\/p>\n<\/li>\n

    • \n

      Creative strategy for remarketing-like scenarios<\/strong><\/p>\n<\/li>\n

    • Multiple creative variants mapped to funnel stages (browse, consider, convert, retain).<\/li>\n
    • \n

      Guardrails to prevent overly personalized messaging that could feel invasive.<\/p>\n<\/li>\n

    • \n

      Ad buying and inventory compatibility<\/strong><\/p>\n<\/li>\n

    • Publisher support and platform support influence available reach.<\/li>\n
    • \n

      Testing plans to understand where the approach is active and where contextual alternatives are needed.<\/p>\n<\/li>\n

    • \n

      Measurement and experimentation<\/strong><\/p>\n<\/li>\n

    • Incrementality testing, holdouts, and conversion modeling become more important as user-level visibility decreases.<\/li>\n
    • \n

      Clear attribution expectations set with stakeholders.<\/p>\n<\/li>\n

    • \n

      Governance and ownership<\/strong><\/p>\n<\/li>\n

    • Defined responsibilities for privacy review, audience taxonomy, retention windows, and incident response\u2014core to Privacy & Consent<\/strong> maturity.<\/li>\n<\/ul>\n\n\n\n

      Types of Protected Audience API<\/h2>\n\n\n\n

      Protected Audience API<\/strong> is best thought of as a concept and capability rather than a single \u201cone-size-fits-all\u201d tactic. The most useful distinctions in practice are:<\/p>\n\n\n\n

        \n
      1. \n

        Remarketing vs. broader interest-based audiences<\/strong>\n – Remarketing audiences are tied to explicit advertiser interactions (product viewers, abandoners).\n – Interest-based audiences may be broader, but still should be grounded in transparent, non-sensitive logic.<\/p>\n<\/li>\n

      2. \n

        On-site engagement segments vs. lifecycle segments<\/strong>\n – Engagement segments reflect short-term intent (last 7 days product views).\n – Lifecycle segments reflect customer state (active subscriber, churn risk) and often require stricter governance.<\/p>\n<\/li>\n

      3. \n

        Pure protected-audience activation vs. hybrid strategies<\/strong>\n – Many teams combine protected-audience approaches with contextual targeting and first-party channels (email, SMS) to balance reach and efficiency.\n – Hybrids are often the most realistic path during transition periods in Privacy & Consent<\/strong> programs.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

        Real-World Examples of Protected Audience API<\/h2>\n\n\n\n

        Example 1: Retail cart recovery without third-party cookies<\/h3>\n\n\n\n

        A retailer creates audiences for \u201cadded to cart\u201d and \u201cviewed category,\u201d with short retention windows and frequency caps. With Protected Audience API<\/strong>, the retailer can show relevant ads on participating publisher inventory without relying on third-party cookies, while keeping the most sensitive user-level data from being shared widely. The consent layer ensures only users who permit the relevant purposes are eligible, reinforcing Privacy & Consent<\/strong> commitments.<\/p>\n\n\n\n

        Example 2: B2B SaaS re-engagement with staged messaging<\/h3>\n\n\n\n

        A SaaS company builds audiences based on first-party milestones: visited pricing, started demo form, completed demo. Ads shown via Protected Audience API<\/strong> use stage-appropriate creatives (case study vs. demo reminder) and exclude existing customers. Measurement focuses on lift versus a holdout group and downstream pipeline quality, supporting Privacy & Consent<\/strong> goals without collapsing performance reporting to vanity clicks.<\/p>\n\n\n\n

        Example 3: Subscription publisher balancing monetization and trust<\/h3>\n\n\n\n

        A publisher enables inventory pathways compatible with protected-audience approaches while maintaining strong contextual targeting. Advertisers can re-engage prior site visitors via Protected Audience API<\/strong>, while the publisher reduces reliance on third-party tracking scripts. This strengthens the publisher\u2019s Privacy & Consent<\/strong> posture and can improve user experience through fewer invasive trackers.<\/p>\n\n\n\n

        Benefits of Using Protected Audience API<\/h2>\n\n\n\n

        When implemented thoughtfully, Protected Audience API<\/strong> can deliver meaningful benefits:<\/p>\n\n\n\n

          \n
        • Performance continuity<\/strong>: preserves remarketing-style conversion efficiency when third-party identifiers decline.<\/li>\n
        • Lower compliance and reputational risk<\/strong>: fewer data-sharing touchpoints can reduce exposure in audits and vendor risk reviews, supporting Privacy & Consent<\/strong> initiatives.<\/li>\n
        • Operational efficiency over time<\/strong>: clearer audience rules, shorter retention, and standardized governance reduce \u201caudience sprawl.\u201d<\/li>\n
        • Improved user experience<\/strong>: fewer cross-site tracking artifacts can mean faster pages and less surprising personalization.<\/li>\n
        • Better long-term adaptability<\/strong>: teams develop stronger experimentation, incrementality, and first-party data practices.<\/li>\n<\/ul>\n\n\n\n

          Challenges of Protected Audience API<\/h2>\n\n\n\n

          Protected Audience API<\/strong> is not a drop-in replacement for legacy tracking. Common challenges include:<\/p>\n\n\n\n

            \n
          • Limited transparency compared to cookie-based logs<\/strong><\/li>\n
          • \n

            Debugging and user-level journey analysis can be constrained, requiring new workflows.<\/p>\n<\/li>\n

          • \n

            Ecosystem fragmentation<\/strong><\/p>\n<\/li>\n

          • \n

            Availability differs by browser support, publisher adoption, and platform integration, complicating media planning.<\/p>\n<\/li>\n

          • \n

            Measurement limitations<\/strong><\/p>\n<\/li>\n

          • \n

            Some attribution approaches become less precise; teams must invest in experiments and aggregated reporting.<\/p>\n<\/li>\n

          • \n

            Implementation complexity<\/strong><\/p>\n<\/li>\n

          • \n

            Engineering, tagging, consent logic, and governance must align; \u201calmost correct\u201d setups often produce misleading results.<\/p>\n<\/li>\n

          • \n

            Policy and sensitivity considerations<\/strong><\/p>\n<\/li>\n

          • Audience definitions must avoid sensitive inferences and remain consistent with Privacy & Consent<\/strong> disclosures and user expectations.<\/li>\n<\/ul>\n\n\n\n

            Best Practices for Protected Audience API<\/h2>\n\n\n\n

            To operationalize Protected Audience API<\/strong> responsibly and effectively:<\/p>\n\n\n\n

              \n
            1. \n

              Start with clear use cases<\/strong>\n – Prioritize high-value remarketing segments (cart abandoners, high-intent visitors) before expanding.<\/p>\n<\/li>\n

            2. \n

              Design audiences for minimization<\/strong>\n – Use short retention windows, avoid unnecessary granularity, and document purpose for each segment.<\/p>\n<\/li>\n

            3. \n

              Make consent states enforceable<\/strong>\n – Ensure your event collection and audience enrollment logic respects consent decisions in real time\u2014central to Privacy & Consent<\/strong> operations.<\/p>\n<\/li>\n

            4. \n

              Use frequency caps and exclusions<\/strong>\n – Prevent fatigue, protect brand perception, and reduce wasted spend.<\/p>\n<\/li>\n

            5. \n

              Invest in experimentation<\/strong>\n – Use A\/B tests, geo tests, and holdouts to measure incrementality rather than relying solely on last-click assumptions.<\/p>\n<\/li>\n

            6. \n

              Align creative with privacy expectations<\/strong>\n – Avoid messaging that reveals inferred attributes; keep personalization \u201chelpful, not spooky.\u201d<\/p>\n<\/li>\n

            7. \n

              Create a governance checklist<\/strong>\n – Define owners, approval workflows, retention policies, and periodic reviews to keep Privacy & Consent<\/strong> controls durable.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

              Tools Used for Protected Audience API<\/h2>\n\n\n\n

              You typically won\u2019t \u201cbuy\u201d a single tool called Protected Audience API<\/strong>. Instead, you operationalize it through a stack that supports privacy-safe activation:<\/p>\n\n\n\n

                \n
              • Consent management platforms<\/strong><\/li>\n
              • \n

                Capture, store, and enforce user choices; provide auditable records for Privacy & Consent<\/strong>.<\/p>\n<\/li>\n

              • \n

                Tag management and event routing<\/strong><\/p>\n<\/li>\n

              • \n

                Control which events fire under which consent states; reduce tag sprawl and improve performance.<\/p>\n<\/li>\n

              • \n

                Analytics and experimentation tools<\/strong><\/p>\n<\/li>\n

              • \n

                Support incrementality testing, cohort analysis, and funnel measurement when user-level identifiers are limited.<\/p>\n<\/li>\n

              • \n

                Ad platforms and demand-side tooling<\/strong><\/p>\n<\/li>\n

              • \n

                Activate audiences and manage bids, creatives, and frequency controls where protected-audience inventory is available.<\/p>\n<\/li>\n

              • \n

                CRM\/CDP systems<\/strong><\/p>\n<\/li>\n

              • \n

                Maintain first-party customer states and suppression lists, ensuring audiences remain accurate and policy-compliant.<\/p>\n<\/li>\n

              • \n

                Reporting dashboards<\/strong><\/p>\n<\/li>\n

              • Combine aggregated ad reporting, on-site conversion metrics, and business KPIs into a single operational view.<\/li>\n<\/ul>\n\n\n\n

                Metrics Related to Protected Audience API<\/h2>\n\n\n\n

                Because Protected Audience API<\/strong> changes how targeting and reporting work, success metrics should cover both performance and governance:<\/p>\n\n\n\n

                  \n
                • Efficiency and outcome metrics<\/strong><\/li>\n
                • \n

                  Cost per acquisition (CPA), cost per lead (CPL), return on ad spend (ROAS), customer acquisition cost (CAC).<\/p>\n<\/li>\n

                • \n

                  Conversion quality<\/strong><\/p>\n<\/li>\n

                • \n

                  Lead-to-opportunity rate, trial-to-paid rate, repeat purchase rate, churn reduction for retention campaigns.<\/p>\n<\/li>\n

                • \n

                  Reach and delivery<\/strong><\/p>\n<\/li>\n

                • \n

                  Incremental reach, frequency, effective CPM, win rate (where available), share of eligible inventory.<\/p>\n<\/li>\n

                • \n

                  On-site behavior<\/strong><\/p>\n<\/li>\n

                • \n

                  Landing page conversion rate, funnel completion rate, time-to-convert, assisted conversions (aggregated).<\/p>\n<\/li>\n

                • \n

                  Privacy & Consent health metrics<\/strong><\/p>\n<\/li>\n

                • Consent opt-in rate by region, tag firing compliance, audience retention adherence, policy exceptions, vendor risk findings.<\/li>\n<\/ul>\n\n\n\n

                  Future Trends of Protected Audience API<\/h2>\n\n\n\n

                  Several trends will shape how Protected Audience API<\/strong> evolves within Privacy & Consent<\/strong> expectations:<\/p>\n\n\n\n

                    \n
                  • More automation with guardrails<\/strong><\/li>\n
                  • \n

                    AI will increasingly optimize bidding and creative rotation, but governance will matter more to prevent sensitive inference and brand risk.<\/p>\n<\/li>\n

                  • \n

                    Stronger aggregated measurement<\/strong><\/p>\n<\/li>\n

                  • \n

                    Expect continued investment in privacy-preserving reporting, modeled conversions, and experiment-driven marketing.<\/p>\n<\/li>\n

                  • \n

                    Hybrid personalization<\/strong><\/p>\n<\/li>\n

                  • \n

                    Contextual signals, first-party relationships, and protected-audience approaches will be blended to balance performance with privacy.<\/p>\n<\/li>\n

                  • \n

                    Rising importance of first-party experience<\/strong><\/p>\n<\/li>\n

                  • \n

                    The quality of your on-site UX, content, and value exchange will drive better audience eligibility and better marketing outcomes.<\/p>\n<\/li>\n

                  • \n

                    Standardization and policy clarity<\/strong><\/p>\n<\/li>\n

                  • As industry norms mature, organizations will treat protected-audience activation as a formal part of Privacy & Consent<\/strong> governance, not an ad-hoc tactic.<\/li>\n<\/ul>\n\n\n\n

                    Protected Audience API vs Related Terms<\/h2>\n\n\n\n

                    Protected Audience API vs third-party cookies<\/strong>\nThird-party cookies store identifiers that multiple parties can read across sites, enabling broad cross-site tracking. Protected Audience API<\/strong> is designed to reduce that exposure by keeping more logic in the browser and limiting the sharing of user-level data.<\/p>\n\n\n\n

                    Protected Audience API vs contextual advertising<\/strong>\nContextual advertising targets based on the content of the page (topic, keywords) rather than user history. Protected Audience API<\/strong> supports audience-based relevance (often tied to prior first-party interactions). In practice, many teams combine both for better coverage and stronger Privacy & Consent<\/strong> alignment.<\/p>\n\n\n\n

                    Protected Audience API vs clean rooms<\/strong>\nClean rooms are controlled environments for privacy-safe analysis and matching, usually for measurement and planning across large datasets. Protected Audience API<\/strong> is about ad selection\/activation in the browser. They can complement each other: clean rooms help evaluate impact; protected-audience tech helps deliver the ads with fewer identifiers.<\/p>\n\n\n\n

                    Who Should Learn Protected Audience API<\/h2>\n\n\n\n
                      \n
                    • Marketers<\/strong> benefit by adapting retargeting and funnel strategies to privacy-preserving constraints while protecting performance.<\/li>\n
                    • Analysts<\/strong> gain new measurement frameworks based on incrementality, cohorts, and aggregated reporting.<\/li>\n
                    • Agencies<\/strong> can guide clients through media planning changes, governance, and testing roadmaps as part of Privacy & Consent<\/strong> transformation.<\/li>\n
                    • Business owners and founders<\/strong> can make better decisions about channel mix, first-party investment, and risk management.<\/li>\n
                    • Developers<\/strong> need to understand implementation patterns, consent enforcement, and the technical tradeoffs that affect performance and compliance.<\/li>\n<\/ul>\n\n\n\n

                      Summary of Protected Audience API<\/h2>\n\n\n\n

                      Protected Audience API<\/strong> is a privacy-preserving approach to audience-based advertising that shifts key targeting and selection functions into the browser. It matters because it helps maintain essential performance marketing use cases\u2014especially remarketing\u2014while reducing broad cross-site tracking and aligning with modern Privacy & Consent<\/strong> expectations. When paired with consent-aware implementation, strong governance, and experiment-based measurement, it supports effective marketing without reverting to invasive data practices, strengthening both outcomes and Privacy & Consent<\/strong> posture.<\/p>\n\n\n\n

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

                      1) What problem does Protected Audience API solve?<\/h3>\n\n\n\n

                      It helps enable audience-based advertising (especially remarketing) without relying on third-party cookies, by keeping more of the audience logic and ad selection in a protected browser context.<\/p>\n\n\n\n

                      2) Is Protected Audience API only for remarketing?<\/h3>\n\n\n\n

                      Remarketing is a primary use case, but the concept can support broader interest-based segments as long as audience rules remain non-sensitive, well-governed, and aligned with user expectations.<\/p>\n\n\n\n

                      3) How does Privacy & Consent affect whether I can use this approach?<\/h3>\n\n\n\n

                      Privacy & Consent<\/strong> determines whether you may collect and use the signals needed to place users into audiences, and what disclosures, controls, and retention limits you must apply. Consent choices should directly control audience enrollment and activation.<\/p>\n\n\n\n

                      4) Will Protected Audience API fully replace third-party cookies for advertising?<\/h3>\n\n\n\n

                      Not fully. It can preserve some performance use cases, but teams typically need a blended strategy that includes contextual targeting, stronger first-party channels, and updated measurement methods.<\/p>\n\n\n\n

                      5) What should I measure if user-level reporting is reduced?<\/h3>\n\n\n\n

                      Focus on incrementality tests, aggregated conversion performance, funnel progression, customer quality metrics, and consent health indicators. This gives a more reliable view than over-optimizing to a single attribution model.<\/p>\n\n\n\n

                      6) Does using Protected Audience API automatically make my marketing compliant?<\/h3>\n\n\n\n

                      No. You still need proper disclosures, lawful basis where applicable, enforceable consent controls, vendor governance, and data minimization. The technology can reduce data exposure, but compliance depends on your full Privacy & Consent<\/strong> program.<\/p>\n\n\n\n

                      7) What\u2019s the first step to implement Protected Audience API responsibly?<\/h3>\n\n\n\n

                      Start by defining a small set of high-intent, first-party audiences with clear retention windows, connect enrollment to consent states, and run controlled experiments to validate lift before scaling.<\/p>\n","protected":false},"excerpt":{"rendered":"

                      Modern advertising is being rebuilt around user choice, data minimization, and safer ways to reach relevant audiences. **Protected Audience API** is one of the most important concepts in that shift: it enables interest-based and remarketing-style advertising without relying on third-party cookies or exposing a person\u2019s browsing history to multiple intermediaries.<\/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":[1916],"tags":[],"class_list":["post-11563","post","type-post","status-publish","format-standard","hentry","category-privacy-consent"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/11563","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=11563"}],"version-history":[{"count":0,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/11563\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/media?parent=11563"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/categories?post=11563"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/tags?post=11563"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}