{"id":11535,"date":"2026-04-02T01:45:09","date_gmt":"2026-04-02T01:45:09","guid":{"rendered":"https:\/\/www.wizbrand.com\/tutorials\/do-not-share\/"},"modified":"2026-04-02T01:45:09","modified_gmt":"2026-04-02T01:45:09","slug":"do-not-share","status":"publish","type":"post","link":"https:\/\/www.wizbrand.com\/tutorials\/do-not-share\/","title":{"rendered":"Do Not Share: What It Is, Key Features, Benefits, Use Cases, and How It Fits in Privacy & Consent"},"content":{"rendered":"\n

\u201cDo Not Share\u201d is a user preference and operational rule that tells an organization not to share an individual\u2019s personal data with other parties for specific purposes\u2014most commonly advertising, tracking, measurement, or enrichment. In Privacy & Consent<\/strong> programs, it functions as a clear boundary: even if data collection is permitted, onward sharing may not be.<\/p>\n\n\n\n

Modern marketing depends on connected data flows across analytics, ad platforms, CRMs, CDPs, and partners. That makes \u201cDo Not Share\u201d central to Privacy & Consent<\/strong> strategy because it directly affects targeting, attribution, identity matching, and partner integrations\u2014while also protecting customer trust and reducing regulatory and reputational risk.<\/p>\n\n\n\n

What Is Do Not Share?<\/h2>\n\n\n\n

At a beginner level, Do Not Share<\/strong> means a person is opting out of having their personal information shared with third parties (or with other business units, depending on policy) for defined uses such as cross-site advertising, data brokering, or partner profiling.<\/p>\n\n\n\n

The core concept is simple: you may still be allowed to collect and use data for essential purposes (like fulfilling an order or securing an account), but you must restrict downstream distribution. This is different from \u201cdo not collect\u201d or \u201cdelete my data\u201d\u2014it\u2019s specifically about sharing<\/strong>.<\/p>\n\n\n\n

From a business perspective, Do Not Share<\/strong> is a governance requirement that changes how systems route data. It forces organizations to implement controls so that certain identifiers, events, or profile attributes are excluded from exports, pixels, server-to-server feeds, and partner APIs.<\/p>\n\n\n\n

Within Privacy & Consent<\/strong>, Do Not Share<\/strong> is one of the most actionable user preferences because it maps directly to technical integrations and vendor relationships. It sits alongside consent choices (opt-in\/opt-out), data rights requests, and preference signals, and it often becomes a key rule in privacy-by-design marketing operations.<\/p>\n\n\n\n

Why Do Not Share Matters in Privacy & Consent<\/h2>\n\n\n\n

Do Not Share<\/strong> matters strategically because sharing is where privacy risk scales. A single data point kept internally may be manageable; the same data distributed across multiple partners increases exposure, accountability complexity, and breach impact.<\/p>\n\n\n\n

It also delivers business value. When you implement Do Not Share<\/strong> cleanly, you reduce accidental policy violations, lower legal and vendor-management overhead, and improve your ability to launch campaigns quickly with confidence that controls are enforced.<\/p>\n\n\n\n

Marketing outcomes are affected in practical ways. Limiting sharing can reduce third-party audience reach or certain forms of cross-context targeting, but it also pushes teams toward higher-quality first-party data strategies, better creative, and more privacy-aware measurement.<\/p>\n\n\n\n

As a competitive advantage, organizations that respect Do Not Share<\/strong> can differentiate on trust. Clear preference handling can reduce churn, improve email engagement, and strengthen brand equity\u2014especially in categories where consumers are sensitive to tracking (finance, health-adjacent services, education, children\u2019s products, and B2B decision-maker data).<\/p>\n\n\n\n

How Do Not Share Works<\/h2>\n\n\n\n

In practice, Do Not Share<\/strong> works as a set of enforceable rules across your data lifecycle:<\/p>\n\n\n\n

    \n
  1. \n

    Input \/ trigger<\/strong>\n A user expresses a preference through a checkbox, privacy center, cookie banner, account setting, or a recognized browser\/device signal. A customer support ticket or formal privacy request may also trigger Do Not Share<\/strong>.<\/p>\n<\/li>\n

  2. \n

    Analysis \/ processing<\/strong>\n Your systems interpret what \u201csharing\u201d means under your policy: which partners count, which purposes are affected (advertising, measurement, enrichment), and which identifiers qualify as personal data. This step typically maps preference states to purpose-based controls.<\/p>\n<\/li>\n

  3. \n

    Execution \/ application<\/strong>\n The preference is stored and propagated (often via a consent string, preference flag, or profile attribute). Downstream connectors enforce it by blocking tags, suppressing exports, filtering server-side events, or limiting fields sent to partners.<\/p>\n<\/li>\n

  4. \n

    Output \/ outcome<\/strong>\n The user\u2019s data is used only within allowed purposes and recipients. Logs, audits, and reporting confirm that restricted data flows did not occur, supporting Privacy & Consent<\/strong> accountability.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

    Key Components of Do Not Share<\/h2>\n\n\n\n

    A robust Do Not Share<\/strong> implementation typically includes:<\/p>\n\n\n\n

      \n
    • Clear definitions and policy mapping<\/strong>: What counts as \u201cshare,\u201d which partners are included, and which purposes are impacted (ads, analytics, personalization, fraud prevention). <\/li>\n
    • Preference capture mechanisms<\/strong>: Cookie consent interfaces, account settings, preference centers, and customer support workflows. <\/li>\n
    • Identity and state management<\/strong>: A way to associate the preference with browsers, devices, and authenticated profiles without over-collecting data. <\/li>\n
    • Enforcement points<\/strong>: Tag management rules, server-side gating, API middleware, ETL filters, and partner export suppression. <\/li>\n
    • Data inventory and vendor governance<\/strong>: A maintained list of integrations, data elements sent, and contractual restrictions. <\/li>\n
    • Auditability<\/strong>: Logs and reports that show what was blocked and why\u2014essential in Privacy & Consent<\/strong> operations. <\/li>\n
    • Team responsibilities<\/strong>: Marketing owns campaign setup, analytics owns measurement logic, engineering owns enforcement, legal\/privacy sets interpretations, and security monitors risk.<\/li>\n<\/ul>\n\n\n\n

      Types of Do Not Share<\/h2>\n\n\n\n

      \u201cDo Not Share\u201d is not always standardized into formal types, but in real organizations it commonly appears in these practical distinctions:<\/p>\n\n\n\n

        \n
      1. \n

        Purpose-based Do Not Share<\/strong>\n Sharing is blocked for advertising purposes but allowed for essential services (payment processors, fraud tools) when necessary.<\/p>\n<\/li>\n

      2. \n

        Partner-category Do Not Share<\/strong>\n Sharing is blocked for ad networks and data brokers, while still permitting tightly controlled processors (email service providers, customer support platforms) under strict contractual terms.<\/p>\n<\/li>\n

      3. \n

        Channel-specific Do Not Share<\/strong>\n Rules vary by channel: web pixels may be blocked, mobile SDK events may be filtered, and offline lists may be restricted from onboarding.<\/p>\n<\/li>\n

      4. \n

        Regional or regulatory Do Not Share<\/strong>\n Depending on jurisdiction, \u201csharing\u201d may have specific meanings. Mature Privacy & Consent<\/strong> programs implement region-aware rules to avoid over- or under-enforcement.<\/p>\n<\/li>\n<\/ol>\n\n\n\n

        Real-World Examples of Do Not Share<\/h2>\n\n\n\n

        Example 1: Ecommerce retargeting suppression<\/strong>\nAn ecommerce brand honors Do Not Share<\/strong> by preventing retargeting pixels from firing for opted-out users and by excluding those users from audience exports to ad platforms. On the backend, server-side event streams filter out advertising-related events while still keeping order confirmation and fraud signals intact. This aligns marketing operations with Privacy & Consent<\/strong> commitments without breaking core business functions.<\/p>\n\n\n\n

        Example 2: B2B lead gen with partner enrichment limits<\/strong>\nA SaaS company captures leads via webinars but offers a \u201cDo Not Share\u201d option in its privacy center. When enabled, the company stops sending lead data to enrichment partners and limits fields shared with webinar co-sponsors. Leads still receive first-party nurture emails (where permitted), but partner distribution is suppressed\u2014reducing risk while maintaining compliant growth workflows under Privacy & Consent<\/strong>.<\/p>\n\n\n\n

        Example 3: Mobile app measurement redesign<\/strong>\nA mobile app team uses Do Not Share<\/strong> to block transmission of device identifiers to certain third parties. They shift measurement toward aggregated reporting, modeled attribution, and first-party event analysis. The result is fewer partner dependencies and a clearer Privacy & Consent<\/strong> story that product and marketing can explain consistently.<\/p>\n\n\n\n

        Benefits of Using Do Not Share<\/h2>\n\n\n\n

        Implemented well, Do Not Share<\/strong> can produce meaningful upside:<\/p>\n\n\n\n

          \n
        • Lower compliance and reputational risk<\/strong> by preventing accidental downstream disclosure. <\/li>\n
        • Cleaner data governance<\/strong> through forced clarity on what data goes where and why. <\/li>\n
        • Higher customer trust<\/strong> when preferences are respected and easy to manage. <\/li>\n
        • Operational efficiency<\/strong> because teams rely on standardized rules rather than ad hoc exceptions. <\/li>\n
        • More resilient measurement<\/strong> as teams invest in first-party analytics, incrementality testing, and privacy-aware reporting instead of fragile third-party tracking. <\/li>\n
        • Cost savings<\/strong> by reducing unnecessary vendor data transfers and limiting over-collection that creates storage and security burden.<\/li>\n<\/ul>\n\n\n\n

          Challenges of Do Not Share<\/h2>\n\n\n\n

          Do Not Share<\/strong> is straightforward conceptually, but difficult operationally:<\/p>\n\n\n\n

            \n
          • Ambiguity in \u201csharing\u201d<\/strong>: Organizations must decide whether certain disclosures count as sharing, especially with complex partner chains. <\/li>\n
          • Preference propagation<\/strong>: The hardest part is making sure the preference follows the user across devices, sessions, and systems without introducing new privacy risk. <\/li>\n
          • Tag sprawl<\/strong>: Legacy pixels, embedded scripts, and \u201cshadow\u201d integrations can bypass intended enforcement. <\/li>\n
          • Measurement limitations<\/strong>: Blocking certain data flows can reduce deterministic attribution and audience matching, requiring new approaches. <\/li>\n
          • Data quality edge cases<\/strong>: Offline imports, call tracking, and CRM syncs may unintentionally reintroduce restricted data to downstream tools. <\/li>\n
          • Organizational friction<\/strong>: Marketing goals can conflict with restrictions unless leadership aligns incentives with Privacy & Consent<\/strong> outcomes.<\/li>\n<\/ul>\n\n\n\n

            Best Practices for Do Not Share<\/h2>\n\n\n\n

            To implement Do Not Share<\/strong> in a durable, scalable way:<\/p>\n\n\n\n

              \n
            1. \n

              Define \u201cshare\u201d in operational terms<\/strong>\n Translate policy language into a concrete matrix: purposes \u00d7 partners \u00d7 data fields \u00d7 channels.<\/p>\n<\/li>\n

            2. \n

              Design for enforcement, not just UI<\/strong>\n A checkbox is not compliance. Ensure the preference controls pixels, APIs, exports, and ETL jobs.<\/p>\n<\/li>\n

            3. \n

              Centralize preference state<\/strong>\n Store a single source of truth (or a synchronized set) and make downstream tools read from it consistently.<\/p>\n<\/li>\n

            4. \n

              Use purpose-based gating<\/strong>\n Tie controls to purposes (advertising, analytics, personalization) so rules remain stable even when vendors change.<\/p>\n<\/li>\n

            5. \n

              Audit regularly<\/strong>\n Run tag scans, review partner payloads, and validate server-side filters. Treat audits as ongoing Privacy & Consent<\/strong> hygiene.<\/p>\n<\/li>\n

            6. \n

              Document exceptions<\/strong>\n If certain processors must receive data to deliver a requested service, document the rationale, scope, and controls.<\/p>\n<\/li>\n

            7. \n

              Train teams with scenarios<\/strong>\n Give marketers and developers playbooks: \u201cIf Do Not Share = true, here\u2019s what changes in campaign setup, reporting, and integrations.\u201d<\/p>\n<\/li>\n<\/ol>\n\n\n\n

              Tools Used for Do Not Share<\/h2>\n\n\n\n

              While Do Not Share<\/strong> is a policy-driven concept, it is operationalized through tool categories commonly used in Privacy & Consent<\/strong> programs:<\/p>\n\n\n\n

                \n
              • Consent management and preference centers<\/strong> to capture and store user choices across web and app experiences. <\/li>\n
              • Tag management systems<\/strong> to block or conditionally fire marketing and analytics tags based on the preference state. <\/li>\n
              • Server-side tracking and event gateways<\/strong> to filter events, remove identifiers, and enforce purpose controls before data reaches partners. <\/li>\n
              • CRM systems and marketing automation platforms<\/strong> to manage first-party communications while preventing restricted exports or syncs. <\/li>\n
              • Data warehouses and ETL\/ELT pipelines<\/strong> to apply suppression logic to datasets and prevent downstream sharing via reverse ETL. <\/li>\n
              • Reporting dashboards and monitoring tools<\/strong> to audit enforcement, spot anomalies, and demonstrate Privacy & Consent<\/strong> compliance.<\/li>\n<\/ul>\n\n\n\n

                Metrics Related to Do Not Share<\/h2>\n\n\n\n

                You can measure Do Not Share<\/strong> effectiveness without turning it into a vanity KPI. Useful metrics include:<\/p>\n\n\n\n

                  \n
                • Preference rate<\/strong>: Percentage of users enabling Do Not Share (overall and by region, channel, device). <\/li>\n
                • Enforcement coverage<\/strong>: Number\/percentage of integrations and data flows governed by Do Not Share rules. <\/li>\n
                • Blocked event volume<\/strong>: Count of pixel fires, API calls, or exports suppressed due to the preference. <\/li>\n
                • Data minimization impact<\/strong>: Reduction in identifiers or sensitive fields sent to partners. <\/li>\n
                • Audit findings<\/strong>: Number and severity of violations or misconfigurations detected over time. <\/li>\n
                • Marketing performance deltas<\/strong>: Changes in CPA\/ROAS, match rates, and attribution confidence after enforcement (interpreted carefully and segmented). <\/li>\n
                • Customer trust indicators<\/strong>: Complaint rate, unsubscribe rate, and support tickets related to privacy choices\u2014often the most practical Privacy & Consent<\/strong> outcome metrics.<\/li>\n<\/ul>\n\n\n\n

                  Future Trends of Do Not Share<\/h2>\n\n\n\n

                  Several trends are shaping how Do Not Share<\/strong> evolves within Privacy & Consent<\/strong>:<\/p>\n\n\n\n

                    \n
                  • AI-driven personalization with tighter controls<\/strong>: As teams use AI for segmentation and creative, more governance will be required to ensure models don\u2019t rely on restricted shared data. <\/li>\n
                  • Automation of preference enforcement<\/strong>: Expect more automated policy-to-control mapping, where declared purposes automatically configure tags, APIs, and exports. <\/li>\n
                  • Shift to first-party and aggregated measurement<\/strong>: Organizations will rely more on modeled attribution, incrementality testing, and on-site analytics, reducing dependence on cross-context data sharing. <\/li>\n
                  • Standardized signals and interoperability<\/strong>: Browser and platform signals may increasingly inform Do Not Share handling, but teams must validate how signals map to their policies. <\/li>\n
                  • Stronger vendor accountability<\/strong>: Contracts, audits, and data processing terms will more explicitly reflect \u201cshare\u201d restrictions, making partner governance a core Privacy & Consent<\/strong> competency.<\/li>\n<\/ul>\n\n\n\n

                    Do Not Share vs Related Terms<\/h2>\n\n\n\n

                    Do Not Share vs Do Not Sell<\/strong>\n\u201cDo not sell\u201d focuses on exchanging personal data for value (often money or other consideration). Do Not Share<\/strong> typically targets disclosure for broader purposes like cross-context advertising, even without direct payment. Many programs treat them together operationally, but the intent and legal triggers can differ by jurisdiction.<\/p>\n\n\n\n

                    Do Not Share vs Opt-out of targeted advertising<\/strong>\nOpting out of targeted ads is purpose-specific: it restricts advertising personalization. Do Not Share<\/strong> may be broader, preventing data disclosure to third parties even when not strictly used for ad targeting (for example, partner profiling or enrichment).<\/p>\n\n\n\n

                    Do Not Share vs Data deletion<\/strong>\nDeletion removes stored data (subject to retention obligations). Do Not Share<\/strong> restricts onward transmission. In practice, teams often need both: deletion for rights requests, and Do Not Share for preference-based ongoing control within Privacy & Consent<\/strong> operations.<\/p>\n\n\n\n

                    Who Should Learn Do Not Share<\/h2>\n\n\n\n
                      \n
                    • Marketers<\/strong> need to understand how Do Not Share<\/strong> changes targeting, retargeting, onboarding, and conversion tracking so campaigns remain effective and compliant. <\/li>\n
                    • Analysts<\/strong> must adjust measurement plans, interpret performance shifts correctly, and help design privacy-aware experiments. <\/li>\n
                    • Agencies<\/strong> should operationalize Do Not Share across client stacks, ensuring tags, audiences, and reporting align with client Privacy & Consent<\/strong> policies. <\/li>\n
                    • Business owners and founders<\/strong> benefit from knowing how preference handling affects growth, risk, and brand trust\u2014especially when entering new regions. <\/li>\n
                    • Developers<\/strong> are essential for implementing enforcement points, server-side filtering, identity logic, and reliable auditing.<\/li>\n<\/ul>\n\n\n\n

                      Summary of Do Not Share<\/h2>\n\n\n\n

                      Do Not Share<\/strong> is a privacy preference and enforcement rule that limits when and how personal data is shared with third parties or across contexts. It matters because sharing is where privacy risk and compliance complexity multiply, and because it reshapes marketing execution and measurement. Within Privacy & Consent<\/strong>, it acts as a practical control layer\u2014turning user choices into real system behavior. Done well, Do Not Share<\/strong> strengthens trust, improves governance, and supports sustainable growth under modern Privacy & Consent<\/strong> expectations.<\/p>\n\n\n\n

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

                      1) What does Do Not Share mean for my marketing campaigns?<\/h3>\n\n\n\n

                      It means some users must be excluded from certain data transfers\u2014like retargeting pixels, audience exports, and partner measurement feeds\u2014depending on your policy definitions and configured purposes.<\/p>\n\n\n\n

                      2) Is Do Not Share the same as opting out of cookies?<\/h3>\n\n\n\n

                      Not necessarily. Cookie choices often control storage or access on a device, while Do Not Share<\/strong> focuses on restricting downstream disclosure of personal data. They overlap in implementation but are not identical.<\/p>\n\n\n\n

                      3) How does Privacy & Consent affect Do Not Share enforcement?<\/h3>\n\n\n\n

                      Privacy & Consent<\/strong> determines how you capture user choices, how you define allowed purposes, and how you prove compliance. Do Not Share is one of the preference states your Privacy & Consent<\/strong> program must reliably apply across tools and partners.<\/p>\n\n\n\n

                      4) Can I still use analytics if a user selects Do Not Share?<\/h3>\n\n\n\n

                      Often yes, if your policy permits analytics under a permitted purpose and you avoid sharing identifiable data with third parties. Many teams use aggregated, first-party, or server-side approaches to stay aligned with Privacy & Consent<\/strong> commitments.<\/p>\n\n\n\n

                      5) Where should the Do Not Share preference be stored?<\/h3>\n\n\n\n

                      Store it in a centralized preference or consent state that can be read by tag rules, backend services, and data pipelines. The key is consistency across channels and systems.<\/p>\n\n\n\n

                      6) How do I verify that Do Not Share is actually working?<\/h3>\n\n\n\n

                      Use audits: tag scans, payload inspections, export logs, and data lineage checks. Track enforcement coverage and blocked event volume, and periodically test real user journeys to confirm Do Not Share<\/strong> rules apply end-to-end.<\/p>\n","protected":false},"excerpt":{"rendered":"

                      \u201cDo Not Share\u201d is a user preference and operational rule that tells an organization not to share an individual\u2019s personal data with other parties for specific purposes\u2014most commonly advertising, tracking, measurement, or enrichment. In **Privacy & Consent** programs, it functions as a clear boundary: even if data collection is permitted, onward sharing may not be.<\/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-11535","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\/11535","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=11535"}],"version-history":[{"count":0,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/posts\/11535\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/media?parent=11535"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/categories?post=11535"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wizbrand.com\/tutorials\/wp-json\/wp\/v2\/tags?post=11535"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}