{"id":7303,"date":"2026-03-24T07:44:15","date_gmt":"2026-03-24T07:44:15","guid":{"rendered":"https:\/\/www.wizbrand.com\/tutorials\/history-change-trigger\/"},"modified":"2026-03-24T07:44:15","modified_gmt":"2026-03-24T07:44:15","slug":"history-change-trigger","status":"publish","type":"post","link":"https:\/\/www.wizbrand.com\/tutorials\/history-change-trigger\/","title":{"rendered":"History Change Trigger: What It Is, Key Features, Benefits, Use Cases, and How It Fits in Tracking"},"content":{"rendered":"\n

Modern websites increasingly behave like apps: content changes instantly without full page reloads. In Conversion & Measurement<\/strong>, that creates a common problem\u2014your analytics and pixels may not \u201csee\u201d new pages, steps, or states. A History Change Trigger<\/strong> solves this by firing Tracking<\/strong> tags when the browser\u2019s history changes (for example, when a single-page application updates the URL via pushState<\/code>, replaceState<\/code>, or the back\/forward buttons).<\/p>\n\n\n\n

In a strong Conversion & Measurement<\/strong> strategy, a History Change Trigger<\/strong> helps you keep funnel data accurate, attribute conversions correctly, and avoid blind spots caused by dynamic navigation. It\u2019s one of the most important concepts for reliable Tracking<\/strong> on modern front ends.<\/p>\n\n\n\n

2) What Is History Change Trigger?<\/h2>\n\n\n\n

A History Change Trigger<\/strong> is a trigger condition used in tag management and instrumentation to detect when a user\u2019s browser URL or history state changes without a traditional page load\u2014and then run specific measurement actions (such as sending a page view, firing an event, or updating marketing pixels).<\/p>\n\n\n\n

The core concept is simple: in many modern interfaces, \u201cnavigation\u201d happens through JavaScript, not server-rendered page loads. The browser\u2019s history stack updates, the URL may change, and the view changes\u2014but standard \u201cpage load\u201d triggers never occur. A History Change Trigger<\/strong> bridges that gap for Tracking<\/strong>.<\/p>\n\n\n\n

From a business perspective, it protects the integrity of Conversion & Measurement<\/strong> by ensuring that key steps (product views, checkout steps, lead-form screens, onboarding stages) are captured as the user moves through an app-like experience. Without it, teams often undercount engagement, misread funnel drop-off, and misattribute conversion performance.<\/p>\n\n\n\n

Within Conversion & Measurement<\/strong>, the History Change Trigger<\/strong> typically sits between front-end navigation behavior and analytics\/tag execution. Inside Tracking<\/strong>, it is the mechanism that tells your tools, \u201cA meaningful navigation happened\u2014measure it.\u201d<\/p>\n\n\n\n

3) Why History Change Trigger Matters in Conversion & Measurement<\/h2>\n\n\n\n

A History Change Trigger<\/strong> matters because measurement gaps usually appear where business impact is highest: landing pages, product pages, pricing flows, checkout steps, and account onboarding. If these transitions occur without a full reload, default Tracking<\/strong> can miss them.<\/p>\n\n\n\n

Strategically, this affects:<\/p>\n\n\n\n

    \n
  • Funnel visibility:<\/strong> If step changes aren\u2019t measured, conversion funnels become misleading, making optimization decisions risky.<\/li>\n
  • Attribution quality:<\/strong> Missing \u201cvirtual pageviews\u201d or state changes can break channel attribution models and inflate or deflate paid performance.<\/li>\n
  • Experimentation confidence:<\/strong> A\/B tests rely on trustworthy instrumentation. Incomplete Conversion & Measurement<\/strong> undermines lift calculations.<\/li>\n
  • Competitive advantage:<\/strong> Teams who implement robust History Change Trigger<\/strong> logic can iterate faster because they can trust what they see in dashboards.<\/li>\n<\/ul>\n\n\n\n

    In short, a History Change Trigger<\/strong> is not a \u201cnice to have\u201d for modern sites; it\u2019s foundational Tracking<\/strong> infrastructure for accurate Conversion & Measurement<\/strong>.<\/p>\n\n\n\n

    4) How History Change Trigger Works<\/h2>\n\n\n\n

    A History Change Trigger<\/strong> is best understood as a practical workflow that connects navigation changes to measurement actions:<\/p>\n\n\n\n

    1) Input \/ Trigger event<\/strong>\nThe app changes the URL or history state without reloading the page. Common drivers include:\n– Internal route changes in a single-page application (SPA)\n– User clicks back\/forward (popstate)\n– Programmatic navigation via pushState<\/code> or replaceState<\/code>\n– Hash-based navigation (in some architectures)<\/p>\n\n\n\n

    2) Detection \/ Processing<\/strong>\nYour instrumentation (often through a tag manager) listens for history changes. When detected, it evaluates conditions such as:\n– Does the new URL match a relevant pattern?\n– Did the route change to a meaningful screen (not just a minor UI state)?\n– Is consent available to run the required Tracking<\/strong> tags?<\/p>\n\n\n\n

    3) Execution \/ Application<\/strong>\nIf conditions are met, measurement actions fire, such as:\n– Sending a virtual page view to analytics\n– Triggering an event for \u201cStep Viewed\u201d\n– Firing advertising pixels for remarketing (where appropriate and consented)\n– Updating data layer variables used by Conversion & Measurement<\/strong><\/p>\n\n\n\n

    4) Output \/ Outcome<\/strong>\nYour reporting reflects the navigation step as if it were a traditional page load\u2014restoring continuity in sessions, funnels, and conversion paths. This improves Tracking<\/strong> accuracy and decision-making.<\/p>\n\n\n\n

    This is why a History Change Trigger<\/strong> is so valuable: it makes app-like navigation measurable in a pageview-centric world, while still supporting event-based Conversion & Measurement<\/strong>.<\/p>\n\n\n\n

    5) Key Components of History Change Trigger<\/h2>\n\n\n\n

    Effective History Change Trigger<\/strong> implementation typically involves these components:<\/p>\n\n\n\n

    Front-end navigation behavior<\/h3>\n\n\n\n

    Your site must update history state in a detectable way. SPAs commonly use the History API; some systems rely on hash routes. Understanding your routing approach is step one for reliable Tracking<\/strong>.<\/p>\n\n\n\n

    Tag management or instrumentation layer<\/h3>\n\n\n\n

    A tag manager or custom measurement wrapper listens for route changes and decides what to fire. This is where the History Change Trigger<\/strong> logic usually lives.<\/p>\n\n\n\n

    Data layer and naming conventions<\/h3>\n\n\n\n

    In strong Conversion & Measurement<\/strong> practice, route changes are paired with structured data:\n– Page\/screen name\n– Content category\n– Funnel step\n– Product identifiers\n– User state (logged in\/out)<\/p>\n\n\n\n

    Clear naming reduces reporting chaos and makes Tracking<\/strong> durable across redesigns.<\/p>\n\n\n\n

    Governance and responsibilities<\/h3>\n\n\n\n

    Because history changes affect many tags, you need ownership:\n– Developers: routing behavior, data layer, technical QA\n– Marketers\/analysts: measurement plan, event taxonomy, validation\n– Privacy\/compliance: consent controls and policies impacting Tracking<\/strong><\/p>\n\n\n\n

    6) Types of History Change Trigger<\/h2>\n\n\n\n

    While \u201cHistory Change Trigger\u201d is a single concept, it appears in a few practical contexts that matter for Conversion & Measurement<\/strong> and Tracking<\/strong>:<\/p>\n\n\n\n

    History API route changes (SPA routing)<\/h3>\n\n\n\n

    This is the most common modern case: navigation updates the URL path (for example, \/pricing<\/code> to \/signup<\/code>) without reload. A History Change Trigger<\/strong> listens for History API changes and fires virtual pageviews or step events.<\/p>\n\n\n\n

    Back\/forward navigation (popstate)<\/h3>\n\n\n\n

    Users often navigate with browser controls. If your Tracking<\/strong> doesn\u2019t account for popstate events, funnels can become inconsistent. A History Change Trigger<\/strong> helps keep state changes measurable even when the user \u201crewinds.\u201d<\/p>\n\n\n\n

    Hash-based navigation (fragment changes)<\/h3>\n\n\n\n

    Some sites encode navigation after #<\/code>. While less common in newer frameworks, it still appears in legacy apps. Measurement may require route detection that treats hash changes as meaningful screens within Conversion & Measurement<\/strong>.<\/p>\n\n\n\n

    Hybrid approaches<\/h3>\n\n\n\n

    Many apps mix history changes with dynamic content updates. In these cases, a History Change Trigger<\/strong> is necessary but not sufficient\u2014you may also need element visibility or custom events to represent meaningful user progress for Tracking<\/strong>.<\/p>\n\n\n\n

    7) Real-World Examples of History Change Trigger<\/h2>\n\n\n\n

    Example 1: Ecommerce SPA product browsing<\/h3>\n\n\n\n

    A retailer\u2019s product listing opens product details by updating the URL and swapping the view without reload. Without a History Change Trigger<\/strong>, analytics won\u2019t record product detail \u201cpageviews,\u201d harming Conversion & Measurement<\/strong> for merchandising and paid landing performance. With the trigger, each product view is recorded as a virtual pageview and\/or \u201cproduct_view\u201d event, improving Tracking<\/strong> for funnel analysis.<\/p>\n\n\n\n

    Example 2: Lead-gen multi-step form<\/h3>\n\n\n\n

    A B2B site uses a multi-step form where each step changes the URL (\/demo?step=2<\/code>) but doesn\u2019t reload. A History Change Trigger<\/strong> fires step-view events so analysts can see where users abandon, enabling conversion rate optimization. This strengthens Conversion & Measurement<\/strong> by separating \u201cform started\u201d from \u201cstep completed\u201d and \u201cform submitted\u201d Tracking<\/strong>.<\/p>\n\n\n\n

    Example 3: Subscription app onboarding flow<\/h3>\n\n\n\n

    A SaaS onboarding wizard updates routes as the user progresses. Marketing wants to retarget users who reached onboarding step 3 but didn\u2019t activate. A History Change Trigger<\/strong> enables consistent Tracking<\/strong> of step screens so audiences can be built accurately (subject to consent and policy), and activation drop-off can be diagnosed.<\/p>\n\n\n\n

    8) Benefits of Using History Change Trigger<\/h2>\n\n\n\n

    Implementing a History Change Trigger<\/strong> correctly can deliver measurable improvements:<\/p>\n\n\n\n

      \n
    • More accurate funnels:<\/strong> Steps are captured consistently, which is essential for Conversion & Measurement<\/strong> optimization.<\/li>\n
    • Better attribution:<\/strong> Virtual pageviews and events restore continuity in user journeys, improving Tracking<\/strong> signals used for channel evaluation.<\/li>\n
    • Faster debugging:<\/strong> When route-based instrumentation is consistent, analysts can isolate issues quickly (for example, one route failing to send events).<\/li>\n
    • Improved audience quality:<\/strong> Remarketing and lifecycle audiences (where permitted) become more reliable because the underlying Tracking<\/strong> is complete.<\/li>\n
    • Reduced measurement debt:<\/strong> You avoid accumulating \u201cunknown\u201d traffic and missing steps that later require costly re-instrumentation.<\/li>\n<\/ul>\n\n\n\n

      9) Challenges of History Change Trigger<\/h2>\n\n\n\n

      A History Change Trigger<\/strong> also introduces complexity that teams should anticipate:<\/p>\n\n\n\n

        \n
      • False positives:<\/strong> Not every URL change is meaningful (filters, sorting parameters, minor UI states). Over-firing harms data quality in Conversion & Measurement<\/strong>.<\/li>\n
      • Duplicate hits:<\/strong> Some apps trigger multiple history changes per interaction. If Tracking<\/strong> fires twice, metrics inflate.<\/li>\n
      • Timing and data readiness:<\/strong> The route may change before the page content or data layer is ready, causing incomplete events (missing IDs, wrong titles).<\/li>\n
      • Cross-domain transitions:<\/strong> Some funnels still leave the SPA for external checkout or identity providers; you must coordinate Tracking<\/strong> across boundaries.<\/li>\n
      • Consent and privacy constraints:<\/strong> Depending on jurisdiction and policy, tags may be blocked until consent is granted, changing what a History Change Trigger<\/strong> is allowed to fire.<\/li>\n<\/ul>\n\n\n\n

        10) Best Practices for History Change Trigger<\/h2>\n\n\n\n

        These practices make History Change Trigger<\/strong> implementations durable and trustworthy:<\/p>\n\n\n\n

        Define what \u201ccounts\u201d as a screen or step<\/h3>\n\n\n\n

        Create a measurement plan that maps routes to business meaning (screen names, funnel steps, content types). This prevents noisy Tracking<\/strong> and supports consistent Conversion & Measurement<\/strong> reporting.<\/p>\n\n\n\n

        Use clear route rules<\/h3>\n\n\n\n

        Avoid firing on every parameter change unless it\u2019s meaningful. Consider:\n– Path-based matching for core screens\n– Parameter-based matching only for critical states (for example, step=3<\/code>)\n– Exclusions for internal UI toggles<\/p>\n\n\n\n

        Control duplicates with safeguards<\/h3>\n\n\n\n

        Add logic to prevent double-firing:\n– Store the last measured route and only fire when it truly changes\n– Debounce rapid route changes\n– Ensure only one virtual pageview per route transition<\/p>\n\n\n\n

        Ensure data is ready before firing<\/h3>\n\n\n\n

        Coordinate with developers so the data layer (product ID, plan name, step number) is populated before Tracking<\/strong> tags run. If needed, fire a custom event after render and use that in combination with the History Change Trigger<\/strong>.<\/p>\n\n\n\n

        Validate continuously<\/h3>\n\n\n\n

        In Conversion & Measurement<\/strong>, treat instrumentation as a living system:\n– QA new releases and routing changes\n– Monitor for sudden drops\/spikes in virtual pageviews or step events\n– Keep a lightweight change log for measurement updates<\/p>\n\n\n\n

        11) Tools Used for History Change Trigger<\/h2>\n\n\n\n

        A History Change Trigger<\/strong> is often implemented and maintained using a combination of tool categories:<\/p>\n\n\n\n

          \n
        • Tag management systems:<\/strong> Configure triggers, conditions, and tag firing rules for Tracking<\/strong> without constant code deployments.<\/li>\n
        • Analytics platforms:<\/strong> Receive virtual pageviews and event data, powering Conversion & Measurement<\/strong> reporting and funnel analysis.<\/li>\n
        • Consent management platforms:<\/strong> Control whether tags can fire on history changes, ensuring compliant Tracking<\/strong> behavior.<\/li>\n
        • Customer data platforms and event pipelines:<\/strong> Standardize event collection and route-based properties for downstream analytics and activation.<\/li>\n
        • Debugging and QA tools:<\/strong> Browser developer tools, tag debuggers, and analytics validation views help verify that the History Change Trigger<\/strong> fires once, fires at the right time, and includes correct parameters.<\/li>\n
        • Reporting dashboards:<\/strong> Aggregate route-based KPIs (step completion, activation rate) into stakeholder-friendly views for ongoing Conversion & Measurement<\/strong>.<\/li>\n<\/ul>\n\n\n\n

          12) Metrics Related to History Change Trigger<\/h2>\n\n\n\n

          To evaluate whether your History Change Trigger<\/strong> setup is working and improving Tracking<\/strong>, monitor:<\/p>\n\n\n\n

            \n
          • Virtual pageviews \/ screen views per session:<\/strong> Sudden drops may indicate broken routing detection; sudden spikes can signal duplicates.<\/li>\n
          • Event volume by route:<\/strong> Look for missing routes or inflated counts after releases.<\/li>\n
          • Funnel step-to-step conversion rate:<\/strong> The primary Conversion & Measurement<\/strong> outcome\u2014step visibility enables accurate drop-off analysis.<\/li>\n
          • Tag firing rate and error rate:<\/strong> If tags fail on certain routes, you\u2019ll see inconsistencies in downstream reporting.<\/li>\n
          • Attribution stability:<\/strong> If channel performance swings after instrumentation changes, confirm you didn\u2019t change how Tracking<\/strong> defines sessions or key steps.<\/li>\n
          • Data completeness:<\/strong> Percentage of events with required properties (step number, product ID, plan name) to ensure analysis quality.<\/li>\n<\/ul>\n\n\n\n

            13) Future Trends of History Change Trigger<\/h2>\n\n\n\n

            Several shifts are shaping how History Change Trigger<\/strong> is used in Conversion & Measurement<\/strong>:<\/p>\n\n\n\n

              \n
            • More event-first measurement:<\/strong> Many teams are moving from pageview-centric models to event schemas. A History Change Trigger<\/strong> still matters, but it increasingly becomes a way to generate consistent \u201cscreen_view\u201d or \u201cstep_view\u201d events.<\/li>\n
            • Automation and anomaly detection:<\/strong> AI-assisted monitoring can flag sudden changes in route-level Tracking<\/strong> volumes, catching broken triggers faster.<\/li>\n
            • Privacy-driven design:<\/strong> Consent-first flows and data minimization will influence which tags can fire on history changes, reinforcing the need for governance in Conversion & Measurement<\/strong>.<\/li>\n
            • Server-side and hybrid measurement:<\/strong> More organizations will route certain data through server-side collection for control and resilience. Even then, the History Change Trigger<\/strong> often remains the client-side signal that a navigation occurred.<\/li>\n
            • Personalization complexity:<\/strong> As experiences become more personalized, routes may not map cleanly to content. Teams will rely more on structured metadata (screen names, content groups) paired with history changes to keep Tracking<\/strong> interpretable.<\/li>\n<\/ul>\n\n\n\n

              14) History Change Trigger vs Related Terms<\/h2>\n\n\n\n

              History Change Trigger vs Pageview (Page Load) Trigger<\/h3>\n\n\n\n

              A pageview trigger fires on full page loads. A History Change Trigger<\/strong> fires when navigation happens without a reload. In modern Conversion & Measurement<\/strong>, you often need both: pageview triggers for traditional pages and history-based triggers for SPA routes.<\/p>\n\n\n\n

              History Change Trigger vs Custom Event Trigger<\/h3>\n\n\n\n

              Custom events are explicitly pushed (often via a data layer) when the app decides something meaningful happened. A History Change Trigger<\/strong> is route-driven. The best Tracking<\/strong> setups frequently combine them: history changes indicate navigation, and custom events confirm that content\/data is ready.<\/p>\n\n\n\n

              History Change Trigger vs DOM Ready \/ Element Visibility Triggers<\/h3>\n\n\n\n

              DOM-based triggers respond to page structure or element appearance. They can work for dynamic content, but they\u2019re more fragile across redesigns. A History Change Trigger<\/strong> is typically more stable for navigation measurement, while DOM triggers help measure in-view components and micro-interactions in Conversion & Measurement<\/strong>.<\/p>\n\n\n\n

              15) Who Should Learn History Change Trigger<\/h2>\n\n\n\n
                \n
              • Marketers:<\/strong> To understand why conversions or funnels may look \u201cwrong\u201d on modern sites and how better Tracking<\/strong> improves optimization.<\/li>\n
              • Analysts:<\/strong> To diagnose missing steps, reconcile funnel anomalies, and build more reliable Conversion & Measurement<\/strong> reporting.<\/li>\n
              • Agencies:<\/strong> To implement durable measurement for clients using SPAs, improving campaign insights and reducing reporting disputes.<\/li>\n
              • Business owners and founders:<\/strong> To ensure growth decisions are based on complete data, not partial journeys caused by broken instrumentation.<\/li>\n
              • Developers:<\/strong> To coordinate routing, data layer timing, and consent-aware Tracking<\/strong> so measurement works without harming performance.<\/li>\n<\/ul>\n\n\n\n

                16) Summary of History Change Trigger<\/h2>\n\n\n\n

                A History Change Trigger<\/strong> is a measurement mechanism that detects browser history or URL changes without a full page reload and fires the right analytics or marketing tags. It matters because modern app-like experiences can otherwise break Tracking<\/strong>, undermining funnels, attribution, and experimentation. In Conversion & Measurement<\/strong>, it restores visibility into key steps and makes reporting trustworthy. Implemented with clear route rules, deduplication, and data readiness checks, a History Change Trigger<\/strong> becomes a cornerstone of reliable digital measurement.<\/p>\n\n\n\n

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

                1) What is a History Change Trigger used for?<\/h3>\n\n\n\n

                A History Change Trigger<\/strong> is used to fire analytics and marketing tags when a site changes state or URL without reloading the page, which is common in single-page applications. It keeps Conversion & Measurement<\/strong> accurate by capturing route-based steps as measurable events.<\/p>\n\n\n\n

                2) When do I need a History Change Trigger instead of a normal pageview trigger?<\/h3>\n\n\n\n

                You need it when users can navigate to new screens (new URLs or states) without a full page load. If your funnels include SPA routes, relying only on pageview triggers will leave gaps in Tracking<\/strong>.<\/p>\n\n\n\n

                3) Can a History Change Trigger cause duplicate analytics hits?<\/h3>\n\n\n\n

                Yes. Some apps generate multiple history updates per interaction. Prevent duplicates by firing only when the route meaningfully changes, debouncing rapid updates, and tracking the last-measured route in your Tracking<\/strong> logic.<\/p>\n\n\n\n

                4) How does a History Change Trigger affect Conversion & Measurement funnels?<\/h3>\n\n\n\n

                It enables consistent step measurement in dynamic flows\u2014product views, checkout steps, onboarding screens\u2014so drop-off and completion rates reflect real behavior rather than missing instrumentation.<\/p>\n\n\n\n

                5) What should I send when the trigger fires: pageviews or events?<\/h3>\n\n\n\n

                Either can work, depending on your analytics approach. Many teams send a virtual pageview\/screen view plus structured events for key actions. The priority is consistency for Conversion & Measurement<\/strong> and clarity in Tracking<\/strong>.<\/p>\n\n\n\n

                6) How do I test whether my Tracking works on SPA route changes?<\/h3>\n\n\n\n

                Use a tag debugging workflow: navigate through routes, confirm the History Change Trigger<\/strong> fires once per intended transition, verify parameters (screen name, step number), and confirm the hits appear correctly in analytics validation views.<\/p>\n\n\n\n

                7) Does privacy consent change what a History Change Trigger can do?<\/h3>\n\n\n\n

                Yes. Even if the History Change Trigger<\/strong> detects navigation, consent rules may restrict which tags can fire. Design Conversion & Measurement<\/strong> so essential, permitted measurement remains reliable while respecting consent and policy constraints.<\/p>\n","protected":false},"excerpt":{"rendered":"

                Modern websites increasingly behave like apps: content changes instantly without full page reloads. In **Conversion & Measurement**, that creates a common problem\u2014your analytics and pixels may not \u201csee\u201d new pages, steps, or states. A **History Change Trigger** solves this by firing **Tracking** tags when the browser\u2019s history changes (for example, when a single-page application updates the URL via `pushState`, `replaceState`, or the back\/forward buttons).<\/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-7303","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\/7303","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=7303"}],"version-history":[{"count":0,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/7303\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/media?parent=7303"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/categories?post=7303"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/tags?post=7303"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}