{"id":6923,"date":"2026-03-23T17:45:29","date_gmt":"2026-03-23T17:45:29","guid":{"rendered":"https:\/\/www.wizbrand.com\/tutorials\/refund-event\/"},"modified":"2026-03-23T17:45:29","modified_gmt":"2026-03-23T17:45:29","slug":"refund-event","status":"publish","type":"post","link":"https:\/\/www.wizbrand.com\/tutorials\/refund-event\/","title":{"rendered":"Refund Event: What It Is, Key Features, Benefits, Use Cases, and How It Fits in Analytics"},"content":{"rendered":"\n

A Refund Event<\/strong> is the moment your measurement stack records that money from a completed purchase has been returned to the customer\u2014whether fully or partially. In Conversion & Measurement<\/strong>, it\u2019s the corrective signal that turns \u201cgross conversions\u201d into \u201cnet business outcomes.\u201d In Analytics<\/strong>, it\u2019s a critical event for aligning marketing performance with financial reality.<\/p>\n\n\n\n

Refunds are unavoidable in many business models: ecommerce returns, subscription cancellations with prorated credits, fulfillment issues, and customer service goodwill gestures. If your reporting treats every purchase as final, you\u2019ll overstate revenue, misread campaign quality, and make budget decisions based on inflated performance. A well-designed Refund Event<\/strong> closes that gap by connecting post-purchase reality back to acquisition, attribution, and lifetime value.<\/p>\n\n\n\n

What Is Refund Event?<\/h2>\n\n\n\n

A Refund Event<\/strong> is a tracked record that a prior transaction has been reversed or partially reversed. It is usually captured as an event in an event-based measurement system (or as a row\/update in transactional reporting) and tied back to the original order or invoice.<\/p>\n\n\n\n

At its core, the concept is simple: a purchase happened, and later some money came back out<\/strong>. The business meaning, however, is richer than \u201cnegative revenue.\u201d A refund can indicate product-market fit issues, shipping and fulfillment problems, misleading messaging, fraud, or even healthy risk-free buying behavior depending on category.<\/p>\n\n\n\n

Within Conversion & Measurement<\/strong>, a Refund Event<\/strong> acts as a post-conversion adjustment that helps you measure:<\/p>\n\n\n\n

    \n
  • Net revenue (after returns)<\/li>\n
  • True customer value (after churn\/refunds)<\/li>\n
  • Channel quality (which sources drive refund-heavy orders)<\/li>\n<\/ul>\n\n\n\n

    Inside Analytics<\/strong>, it becomes an essential input for revenue integrity, cohort analysis, attribution, and profitability reporting.<\/p>\n\n\n\n

    Why Refund Event Matters in Conversion & Measurement<\/h2>\n\n\n\n

    A Refund Event<\/strong> matters because many marketing metrics are only meaningful when they reflect what the business actually keeps. If you optimize on gross purchases alone, you can inadvertently scale campaigns that generate high purchase volume but poor retention, high return rates, or low customer satisfaction.<\/p>\n\n\n\n

    Strategically, Conversion & Measurement<\/strong> improves when refunds are measured because you can:<\/p>\n\n\n\n

      \n
    • Protect budgets and improve ROI:<\/strong> Refund-adjusted ROAS or profit per click is harder to game and more aligned with business goals.<\/li>\n
    • Improve targeting and messaging:<\/strong> If certain audiences refund more often, your segmentation and creative strategy can adapt.<\/li>\n
    • Spot operational issues early:<\/strong> Spikes in refund volume can be a leading indicator of product defects, shipping delays, or policy confusion.<\/li>\n
    • Gain competitive advantage:<\/strong> Teams that integrate Refund Event<\/strong> data into Analytics<\/strong> can out-optimize competitors who only track purchases.<\/li>\n<\/ul>\n\n\n\n

      Ultimately, refunds aren\u2019t just a finance issue\u2014they\u2019re a performance signal that should influence acquisition strategy, landing pages, onboarding flows, and retention efforts.<\/p>\n\n\n\n

      How Refund Event Works<\/h2>\n\n\n\n

      In practice, a Refund Event<\/strong> is the result of a lifecycle that starts after the initial conversion:<\/p>\n\n\n\n

        \n
      1. \n

        Input \/ trigger<\/strong>\n A refund is initiated through a commerce system, payment processor, customer support platform, or subscription billing tool. Triggers include returns, cancellations, charge disputes resolved as refunds, or manual refunds.<\/p>\n<\/li>\n

      2. \n

        Processing \/ mapping<\/strong>\n The system reconciles the refund to an original transaction using identifiers (order ID, invoice ID, transaction ID). Good implementations ensure idempotency (the same refund isn\u2019t counted twice) and handle partial refunds across multiple items or taxes.<\/p>\n<\/li>\n

      3. \n

        Execution \/ measurement capture<\/strong>\n The refund is recorded into your tracking plan as a Refund Event<\/strong> with consistent fields (amount, currency, items, reason, timestamp). This may happen client-side, server-side, or via a data pipeline.<\/p>\n<\/li>\n

      4. \n

        Output \/ outcome in reporting<\/strong>\nAnalytics<\/strong> and reporting layers use the Refund Event<\/strong> to adjust revenue, update cohorts, and refine Conversion & Measurement<\/strong> views such as CAC payback, LTV, and attribution performance.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

        The key idea: a refund is not merely \u201cnegative purchase.\u201d It\u2019s a structured business event that should connect back to the original conversion and the marketing context that produced it.<\/p>\n\n\n\n

        Key Components of Refund Event<\/h2>\n\n\n\n

        A reliable Refund Event<\/strong> depends on more than a single number. The most useful implementations include:<\/p>\n\n\n\n

        Data inputs (recommended fields)<\/h3>\n\n\n\n
          \n
        • Original transaction identifier:<\/strong> order_id \/ invoice_id \/ transaction_id <\/li>\n
        • Refund identifier:<\/strong> refund_id (for deduplication and auditing) <\/li>\n
        • Refund amount and currency:<\/strong> including tax\/shipping handling where relevant <\/li>\n
        • Refund scope:<\/strong> full vs partial, and which line items were refunded <\/li>\n
        • Timestamp:<\/strong> refund time (and optionally refund requested time) <\/li>\n
        • Reason code:<\/strong> return, cancellation, damaged, fraud, goodwill, etc. <\/li>\n
        • Customer identifier:<\/strong> consistent with privacy and consent requirements <\/li>\n
        • Acquisition context:<\/strong> channel\/source\/campaign where available (often joined later)<\/li>\n<\/ul>\n\n\n\n

          Systems and processes<\/h3>\n\n\n\n
            \n
          • Commerce\/billing system:<\/strong> where the refund is created <\/li>\n
          • Payment reconciliation:<\/strong> ensures the refund is real and completed, not just requested <\/li>\n
          • Tracking plan governance:<\/strong> naming conventions, required properties, QA rules <\/li>\n
          • Team responsibilities:<\/strong> marketing, finance, support, and data\/engineering alignment<\/li>\n<\/ul>\n\n\n\n

            Metrics and reporting logic<\/h3>\n\n\n\n
              \n
            • Net revenue and refund rate definitions<\/li>\n
            • Attribution treatment rules (what happens to credited conversions when refunded)<\/li>\n
            • Data freshness expectations (refunds often lag purchases)<\/li>\n<\/ul>\n\n\n\n

              These components make the Refund Event<\/strong> useful in both Conversion & Measurement<\/strong> operations and Analytics<\/strong> interpretation.<\/p>\n\n\n\n

              Types of Refund Event<\/h2>\n\n\n\n

              \u201cRefund\u201d is one word, but the measurement context differs. Common, practical distinctions include:<\/p>\n\n\n\n

              Full vs partial refunds<\/h3>\n\n\n\n
                \n
              • Full refund:<\/strong> entire order amount reversed <\/li>\n
              • Partial refund:<\/strong> subset of items, shipping, tax, or a goodwill adjustment\nPartial refunds require line-item detail if you want product-level Analytics<\/strong>.<\/li>\n<\/ul>\n\n\n\n

                Immediate vs delayed refunds<\/h3>\n\n\n\n
                  \n
                • Immediate:<\/strong> cancellation before fulfillment or shortly after purchase <\/li>\n
                • Delayed:<\/strong> returns after delivery, refunds after support escalation\nDelayed refunds are especially important for cohort-based Conversion & Measurement<\/strong>.<\/li>\n<\/ul>\n\n\n\n

                  Automated vs manual refunds<\/h3>\n\n\n\n
                    \n
                  • Automated:<\/strong> policy-driven refunds (subscription trials, SLA credits) <\/li>\n
                  • Manual:<\/strong> customer support or operations-initiated refunds\nManual refunds often benefit from mandatory \u201creason\u201d capture to support analysis.<\/li>\n<\/ul>\n\n\n\n

                    Refunds vs store credit<\/h3>\n\n\n\n

                    In some businesses, the customer receives store credit rather than cash back. You may still track this as a Refund Event<\/strong>, but you should classify it clearly because the financial and retention implications differ.<\/p>\n\n\n\n

                    Real-World Examples of Refund Event<\/h2>\n\n\n\n

                    Example 1: Ecommerce return impacts campaign profitability<\/h3>\n\n\n\n

                    A retailer runs paid social campaigns optimized for purchases. Purchases look strong, but a portion of orders are returned due to sizing issues. By tracking a Refund Event<\/strong> tied to the original order, the team updates Conversion & Measurement<\/strong> dashboards to show refund-adjusted revenue by campaign. Analytics<\/strong> reveals that one creative angle drives higher return rates, prompting a messaging change and better product page guidance.<\/p>\n\n\n\n

                    Example 2: SaaS annual plan refund window changes attribution outcomes<\/h3>\n\n\n\n

                    A SaaS company sells annual plans with a 30-day money-back guarantee. Many customers refund after onboarding friction. Capturing Refund Event<\/strong> data allows the company to evaluate \u201cnet trials-to-paid\u201d and refund-adjusted LTV by channel. In Analytics<\/strong>, the team sees that one affiliate source produces high initial conversions but a disproportionate share of refunds\u2014leading to revised commission rules and improved onboarding.<\/p>\n\n\n\n

                    Example 3: Subscription proration and partial refunds clarify retention<\/h3>\n\n\n\n

                    A subscription business issues prorated refunds on mid-cycle cancellations. Without partial Refund Event<\/strong> tracking, net revenue is overstated and churn analysis is distorted. With accurate event properties, Conversion & Measurement<\/strong> reports can separate true churn from billing adjustments and provide cleaner cohort profitability.<\/p>\n\n\n\n

                    Benefits of Using Refund Event<\/h2>\n\n\n\n

                    Implementing Refund Event<\/strong> tracking improves performance and decision-making in several concrete ways:<\/p>\n\n\n\n

                      \n
                    • More accurate ROI and budget allocation:<\/strong> Refund-adjusted revenue helps you invest in channels that generate durable value. <\/li>\n
                    • Better funnel truth:<\/strong> Purchases become \u201cprovisional\u201d until refund windows pass, improving the integrity of Analytics<\/strong>. <\/li>\n
                    • Higher efficiency in optimization:<\/strong> You can optimize toward net revenue, profit, or retained customers instead of raw conversion volume. <\/li>\n
                    • Improved customer experience insight:<\/strong> Refund reasons reveal friction points in product, delivery, or expectations. <\/li>\n
                    • Stronger forecasting:<\/strong> Finance and marketing forecasts align when Conversion & Measurement<\/strong> includes post-purchase corrections.<\/li>\n<\/ul>\n\n\n\n

                      Challenges of Refund Event<\/h2>\n\n\n\n

                      A Refund Event<\/strong> is conceptually simple but often difficult to measure well:<\/p>\n\n\n\n

                        \n
                      • Identity and matching issues:<\/strong> If order IDs differ across systems, joining refunds to purchases becomes error-prone. <\/li>\n
                      • Timing and latency:<\/strong> Refunds can occur days or weeks after purchase, complicating period reporting and experimentation readouts. <\/li>\n
                      • Partial refund complexity:<\/strong> Item-level refunds, tax\/shipping adjustments, and multi-tender payments introduce edge cases. <\/li>\n
                      • Deduplication risks:<\/strong> Retries, webhooks, and manual processes can create duplicate refund records without careful design. <\/li>\n
                      • Attribution ambiguity:<\/strong> Deciding how a refund affects credited conversions can be politically and analytically sensitive. <\/li>\n
                      • Privacy and consent constraints:<\/strong> Passing customer identifiers into Analytics<\/strong> must respect consent, retention policies, and data minimization.<\/li>\n<\/ul>\n\n\n\n

                        Recognizing these challenges early helps teams design more resilient Conversion & Measurement<\/strong> frameworks.<\/p>\n\n\n\n

                        Best Practices for Refund Event<\/h2>\n\n\n\n

                        To make a Refund Event<\/strong> trustworthy and useful, focus on implementation discipline and reporting clarity:<\/p>\n\n\n\n

                          \n
                        1. \n

                          Define it in a tracking plan<\/strong>\n Specify event name, required properties, allowed values, and examples. Include rules for full vs partial refunds.<\/p>\n<\/li>\n

                        2. \n

                          Always include stable identifiers<\/strong>\n Capture original transaction ID and a unique refund ID. This is the foundation for joining data and preventing duplicates.<\/p>\n<\/li>\n

                        3. \n

                          Track both amount and context<\/strong>\n Record currency, tax\/shipping handling, and reason codes. Without context, Analytics<\/strong> can\u2019t explain \u201cwhy.\u201d<\/p>\n<\/li>\n

                        4. \n

                          Use server-to-server capture when possible<\/strong>\n Refunds often happen off-site (support actions, billing systems). Server-side capture improves completeness in Conversion & Measurement<\/strong>.<\/p>\n<\/li>\n

                        5. \n

                          Build refund-adjusted reporting views<\/strong>\n Maintain clear definitions for:\n – Gross revenue (purchases)\n – Refunded revenue (sum of Refund Event<\/strong> amounts)\n – Net revenue (gross minus refunds)<\/p>\n<\/li>\n

                        6. \n

                          Monitor data quality continuously<\/strong>\n Use alerts for spikes in refund rate, missing identifiers, negative net revenue anomalies, or unusual refund reasons.<\/p>\n<\/li>\n

                        7. \n

                          Align stakeholders on attribution handling<\/strong>\n Decide whether refunds reverse conversion credit, reduce credited revenue, or only affect profitability reporting. Document the approach.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

                          Tools Used for Refund Event<\/h2>\n\n\n\n

                          A Refund Event<\/strong> is typically managed across a stack rather than in one tool. Common tool categories include:<\/p>\n\n\n\n

                            \n
                          • Analytics tools:<\/strong> event collection, user journeys, cohort analysis, and funnel reporting that incorporate refunds into outcomes. <\/li>\n
                          • Data pipelines and warehouses:<\/strong> to unify commerce, billing, support, and marketing data; essential for refund-to-order joins. <\/li>\n
                          • Tag management and server-side tracking systems:<\/strong> to standardize event schemas and improve data reliability. <\/li>\n
                          • CRM and customer support systems:<\/strong> sources of refund reasons, case context, and customer history. <\/li>\n
                          • Ad platforms and measurement integrations:<\/strong> for aligning conversion value with net outcomes (where policy and capabilities allow). <\/li>\n
                          • Reporting dashboards and BI:<\/strong> to publish refund-adjusted Conversion & Measurement<\/strong> KPIs to stakeholders. <\/li>\n
                          • SEO tools (indirectly):<\/strong> to connect landing page intent and content expectations to downstream refund behavior when joined with Analytics<\/strong>.<\/li>\n<\/ul>\n\n\n\n

                            The goal is not \u201cmore tools,\u201d but a consistent, auditable path from refund creation to measurement and decision-making.<\/p>\n\n\n\n

                            Metrics Related to Refund Event<\/h2>\n\n\n\n

                            To operationalize Refund Event<\/strong> data, track metrics that connect refunds to both marketing and business health:<\/p>\n\n\n\n

                              \n
                            • Refund rate:<\/strong> refunds \u00f7 purchases (by count) and refunded revenue \u00f7 gross revenue (by value) <\/li>\n
                            • Net revenue:<\/strong> gross revenue \u2212 refunded revenue <\/li>\n
                            • Refund-adjusted ROAS \/ ROI:<\/strong> ad-attributed net revenue \u00f7 spend (definition must be consistent) <\/li>\n
                            • Time-to-refund:<\/strong> average days from purchase to Refund Event<\/strong> (useful for forecasting and cohort analysis) <\/li>\n
                            • Refund reasons distribution:<\/strong> percent by reason code (find operational or expectation issues) <\/li>\n
                            • Refunds by channel\/campaign\/creative:<\/strong> identifies low-quality acquisition sources <\/li>\n
                            • Repeat refunders \/ anomaly flags:<\/strong> can indicate fraud, misuse, or poor product fit <\/li>\n
                            • LTV after refunds:<\/strong> lifetime value recalculated using net revenue, improving Conversion & Measurement<\/strong> accuracy<\/li>\n<\/ul>\n\n\n\n

                              Good Analytics<\/strong> practice separates \u201cwhat happened\u201d (refund) from \u201cwhy\u201d (reason) and \u201cwhere it came from\u201d (attribution).<\/p>\n\n\n\n

                              Future Trends of Refund Event<\/h2>\n\n\n\n

                              Several trends are changing how teams treat refunds in Conversion & Measurement<\/strong>:<\/p>\n\n\n\n

                                \n
                              • AI-assisted root cause analysis:<\/strong> Models can cluster refund reasons, detect anomalies, and predict refund likelihood based on product, delivery, and acquisition signals. <\/li>\n
                              • More automation and real-time reconciliation:<\/strong> Faster pipelines make refund-adjusted reporting available sooner for budget decisions. <\/li>\n
                              • Personalization to prevent refunds:<\/strong> Using behavioral and support signals to intervene before returns (better sizing guidance, onboarding help, proactive support). <\/li>\n
                              • Privacy-driven measurement shifts:<\/strong> As identifiers become more restricted, Analytics<\/strong> will rely more on aggregated reporting, server-side events, and careful consent management. <\/li>\n
                              • Profit-based optimization:<\/strong> Teams increasingly optimize toward contribution margin, where Refund Event<\/strong> data is a non-negotiable input.<\/li>\n<\/ul>\n\n\n\n

                                As measurement matures, Refund Event<\/strong> tracking evolves from a \u201cnice-to-have correction\u201d to a core performance signal.<\/p>\n\n\n\n

                                Refund Event vs Related Terms<\/h2>\n\n\n\n

                                Refund Event vs Purchase Event<\/h3>\n\n\n\n

                                A purchase event records the initial conversion and gross revenue. A Refund Event<\/strong> records the reversal and adjusts outcomes. In Conversion & Measurement<\/strong>, both are needed to understand net performance.<\/p>\n\n\n\n

                                Refund Event vs Chargeback<\/h3>\n\n\n\n

                                A chargeback is a payment dispute initiated through the bank\/card network. It can result in a reversal, but the lifecycle, fees, and fraud implications differ. Many teams track chargebacks separately and may also record a Refund Event<\/strong> only when a refund is actually issued.<\/p>\n\n\n\n

                                Refund Event vs Return<\/h3>\n\n\n\n

                                A return is the logistics\/customer action of sending items back; a refund is the financial action. You can have returns without immediate refunds (inspection period) and refunds without returns (goodwill). Analytics<\/strong> improves when these are distinct but linkable.<\/p>\n\n\n\n

                                Who Should Learn Refund Event<\/h2>\n\n\n\n
                                  \n
                                • Marketers:<\/strong> to optimize campaigns on net outcomes and avoid scaling refund-heavy acquisition. <\/li>\n
                                • Analysts:<\/strong> to build accurate models of LTV, cohort profitability, and refund-adjusted attribution in Analytics<\/strong>. <\/li>\n
                                • Agencies:<\/strong> to report performance credibly and defend strategy with finance-aligned Conversion & Measurement<\/strong>. <\/li>\n
                                • Business owners and founders:<\/strong> to understand whether growth is durable or inflated by reversible sales. <\/li>\n
                                • Developers and data engineers:<\/strong> to implement reliable event schemas, deduplication, and cross-system joins that make the Refund Event<\/strong> trustworthy.<\/li>\n<\/ul>\n\n\n\n

                                  Summary of Refund Event<\/h2>\n\n\n\n

                                  A Refund Event<\/strong> is the tracked record of money returned after a purchase, captured in a way that ties back to the original transaction. It matters because modern Conversion & Measurement<\/strong> requires net, finance-aligned outcomes\u2014not just gross conversions. When modeled correctly, Refund Event<\/strong> data strengthens Analytics<\/strong> by improving attribution realism, cohort truth, profitability reporting, and operational visibility.<\/p>\n\n\n\n

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

                                  1) What should a Refund Event include to be useful?<\/h3>\n\n\n\n

                                  At minimum: original transaction ID, unique refund ID, refund amount, currency, timestamp, and whether it\u2019s full or partial. Adding reason codes and item-level details makes Analytics<\/strong> far more actionable.<\/p>\n\n\n\n

                                  2) How does Refund Event tracking affect Conversion & Measurement reporting?<\/h3>\n\n\n\n

                                  It enables refund-adjusted KPIs such as net revenue, refund-adjusted ROAS, and LTV after refunds. This reduces over-reporting and improves budget decisions.<\/p>\n\n\n\n

                                  3) Should a Refund Event reverse conversion credit in attribution?<\/h3>\n\n\n\n

                                  It depends on your governance. Some teams reverse the conversion, others subtract refunded revenue from attributed revenue, and some only adjust profitability views. The best approach is the one you document and apply consistently across Conversion & Measurement<\/strong>.<\/p>\n\n\n\n

                                  4) What\u2019s the difference between refund rate by count and by value?<\/h3>\n\n\n\n

                                  By count measures the share of orders refunded. By value measures the share of revenue refunded. High-value partial refunds may barely affect counts but significantly impact net revenue in Analytics<\/strong>.<\/p>\n\n\n\n

                                  5) How do refunds show up in Analytics if the refund happens offline?<\/h3>\n\n\n\n

                                  Offline refunds should be captured server-side from billing\/commerce systems and sent through your data pipeline. Relying only on browser-based tracking often misses these Refund Event<\/strong> records.<\/p>\n\n\n\n

                                  6) Can Refund Event data help improve customer experience?<\/h3>\n\n\n\n

                                  Yes. Reason codes and time-to-refund trends reveal where expectations break (product quality, shipping delays, unclear messaging). That insight can guide content, onboarding, support workflows, and product changes.<\/p>\n\n\n\n

                                  7) How soon should we report on Refund Event metrics after a campaign launch?<\/h3>\n\n\n\n

                                  Track them immediately, but interpret early results cautiously because refunds lag purchases. Many teams use rolling windows (e.g., 7\/14\/30 days) in Analytics<\/strong> to align reporting with typical refund behavior.<\/p>\n","protected":false},"excerpt":{"rendered":"

                                  A **Refund Event** is the moment your measurement stack records that money from a completed purchase has been returned to the customer\u2014whether fully or partially. In **Conversion & Measurement**, it\u2019s the corrective signal that turns \u201cgross conversions\u201d into \u201cnet business outcomes.\u201d In **Analytics**, it\u2019s a critical event for aligning marketing performance with financial reality.<\/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":[1887],"tags":[],"class_list":["post-6923","post","type-post","status-publish","format-standard","hentry","category-analytics"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/6923","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=6923"}],"version-history":[{"count":0,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/6923\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/media?parent=6923"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/categories?post=6923"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/tags?post=6923"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}