HN Debrief

I've always wondered if anyone used sharing buttons on news sites and blogs

  • Product
  • Privacy
  • Web
  • Analytics

The post looked at share-button usage on GOV.UK and found that only 14,078 clicks came from roughly 6.7 million page views, then used that 0.21% rate to argue that almost nobody uses share buttons on news sites and blogs. The reaction was that the number does not support the headline. For a voluntary action that only a small slice of visitors would ever want, 0.21% is not trivial. Several people with product, publishing, analytics, and marketing experience said getting users to do anything on a page is hard, and that this rate could still justify the small surface area if sharing brings in valuable visitors.

Do not judge a feature like share buttons by gut feel alone. If you keep sharing affordances, favor simple copy-link or native OS share flows, measure incremental sharing rather than raw clicks, and treat third-party social widgets as a privacy and UX cost that needs real justification.

Discussion mood

Mostly skeptical of the article’s conclusion, with a broad view that 0.21% is a respectable interaction rate for an optional action. The stronger negativity was aimed at traditional social share buttons themselves, which people see as tracking-heavy, inconsistent, and worse than copy-link or native share patterns.

Key insights

  1. 01

    Control beats canned sharing flows

    What people want from sharing is a clean link they can send in their own channel, with their own words. Once a button starts adding promo text, shortlinks, timestamps, identity hints, or tracking parameters, it stops feeling like help and starts feeling like the site is using the sender. That explains why copy-paste remains the trusted default even when dedicated share UI exists.

    If you add sharing, make the default output inspectable and clean. Audit what your share flow copies or generates, and strip anything a sender would feel the need to clean up by hand.

      Attribution:
    • joshstrange #1 #2
    • theturtletalks #1 #2
    • spockz #1
    • broodbucket #1
    • NikolaNovak #1
  2. 02

    Native share works best as a mobile fallback

    OS-level sharing solves part of the problem because users already know the destination picker on their phone. It is much weaker on desktop, uneven across browsers, and sometimes a dead end in WebView-heavy environments. That is why the most practical pattern was not “use native share everywhere” but “offer native share where supported, and always pair it with copy link.”

    Treat native sharing as progressive enhancement, not your only sharing mechanism. Design the feature so desktop and unsupported mobile browsers still get a one-tap copy-link path.

      Attribution:
    • ndegruchy #1
    • input_sh #1
    • rickstanley #1
    • imoverclocked #1
    • yieldcrv #1
    • mgiampapa #1
    • TrackerFF #1
    • TheRoque #1
  3. 03

    Clicks alone do not prove feature value

    A share-button click count is only meaningful if it measures incremental sharing instead of merely one sharing path. People may share by copying the URL after seeing the call to action, or certain pages may drive nearly all of the activity while most pages never will. The useful evaluation is page-level and outcome-based, not a sitewide average presented as a verdict on the whole pattern.

    Measure whether sharing affordances increase downstream referral traffic or sharing on high-intent pages. Do not kill or keep the feature based on a blunt sitewide click-through number.

      Attribution:
    • Grombobulous #1
    • dewey #1
    • donohoe #1
    • mattjoyce #1
  4. 04

    Structured payloads are what actually get shared

    Share buttons become compelling when they package user-generated context that is annoying to recreate manually. Wordle worked because it shared a scorecard, not just a link. The same logic applies to train schedules, calculator states, game results, and timestamped media. In those cases the button is closer to an export function than a social widget.

    Use share UI for stateful or personalized outputs where the shared object has standalone value. For ordinary article pages, a generic social bar is unlikely to add much.

      Attribution:
    • klinquist #1
    • brikym #1
    • andy_ppp #1
    • blitzar #1
    • smcin #1
  5. 05

    Third-party share widgets are a data collection trade

    Several comments argued that embedded social buttons survived partly because they let Google, Meta, and others observe browsing behavior, not because they were a great user feature. Cookie partitioning blunts some of that, but fingerprinting and other tracking still make these widgets a privacy liability. That changes the cost side of the feature from “a little clutter” to “a real trust and compliance choice.”

    If your share button depends on third-party scripts or embeds, treat it like any other tracking integration. Review it with the same scrutiny you would apply to analytics tags or ad tech.

      Attribution:
    • PaulHoule #1
    • fmajid #1
    • dewey #1
  6. 06

    Audience and context matter more than ideology

    A clean copy-link flow is obvious to technical users, but not to everyone. Older users and less confident users may genuinely need visible sharing UI. Likewise, mobile apps often hide canonical links, which makes built-in sharing more valuable than it is on the open web. A government page, a media site, and an app each have different sharing jobs.

    Segment by user capability and platform before removing sharing controls. What looks like clutter to power users may still remove real friction for mobile or older audiences.

      Attribution:
    • iknowstuff #1
    • deepsun #1
    • catlikesshrimp #1

Against the grain

  1. 01

    The headline is still directionally right

    Even people who accepted that 0.21% is not mathematically tiny still felt the plain-language claim lands. For most site owners, a feature used by a fraction of a percent will feel like “basically nobody,” especially when the comparison is against more important work. This framing changes the decision from statistical significance to product priority.

    Do not let a defensible conversion rate distract from opportunity cost. A feature can be real, measurable, and still not deserve design attention or page chrome on your site.

      Attribution:
    • nkrisc #1
    • raincole #1
    • preciousoo #1 #2
    • deadbabe #1
  2. 02

    Users do not notice tracking enough to change behavior

    One line of argument was bluntly commercial. Most people either do not know or do not care that share widgets track them, and the small group that does often blocks the scripts already. If you are optimizing for convenience or growth rather than principle, that makes the integration easy to justify despite the privacy objections.

    Assume privacy objections alone will not reduce usage enough to rescue a bad integration decision. If you care about user trust, you need an explicit product stance, not faith that users will self-protect.

      Attribution:
    • bluebarbet #1
    • vovavili #1 #2
    • 9dev #1
    • mvdtnz #1

In plain english

`navigator.share()` ↩
A web browser API that opens the device’s native share sheet so a user can send a page or content to another app.
cookie partitioning ↩
A browser privacy feature that limits how cookies can track a user across different websites.
GOV.UK ↩
The main United Kingdom government website for public services and information.
OS ↩
Operating system, the core software on a device such as iOS, Android, Windows, or macOS.
URL ↩
Uniform Resource Locator, the web address of a page or resource.
WebView ↩
A component inside a mobile app that displays web pages without opening a full browser app.

Reference links

Web sharing APIs and platform behavior

Examples of share UI in products

HN links used as examples