I’m building LinksRF to make shared-link traffic easier to understand
I'm building LinksRF, a bootstrapped platform for creating, sharing, and understanding campaign links.
The idea came from a simple problem: a "view" does not always mean a person actually visited.
A link may be requested by a real visitor, an AI agent, social preview generator, search crawler, security scanner, monitoring service, or automated script. When everything is combined into a single click count, it becomes difficult to understand what genuinely happened.
LinksRF tries to make that traffic more explainable by separating:
- Likely human visitors
- Confirmed behavioral engagement
- Social and messaging previews
- Verified crawlers and bots
- AI and automated agents
- Security scanners
- Suspicious or repeated scripted traffic
- Raw requests that cannot yet be confidently classified
Alongside traffic-quality analytics, LinksRF includes:
- Short and readable campaign links
- Branded custom domains
- UTM campaign tracking
- Shareable boards and resource collections
- Bio pages and focused funnels
- Sources, devices, locations, and returning-visitor insights
Teams, workspaces, and campaign management
The goal is not to claim that every visitor can be identified perfectly. It is to provide better evidence than a single raw number and clearly communicate when the system is uncertain.
LinksRF is still early, bootstrapped, and launching on Product Hunt this Monday.
I'd really appreciate honest feedback:
When reviewing link analytics, what would help you trust that the traffic represented genuine interest rather than previews or automation?
The 'clearly communicate when the system is uncertain' framing is the part that matters most most analytics tools just pick a confident-looking bucket even when the signal's ambiguous, which quietly trains people to over-trust the numbers. To actually answer your question: I'd trust it more if I could see why something got classified a certain way, not just t e.g., 'flagged as bot due to request pattern X' versus a black-box score. Same principle that builds trust in any automated system, really.
I completely agree. That's one of the principles behind LinksRF.
Rather than forcing every request into a confident-looking bucket, we try to communicate when the evidence is strong and when it isn't.
We also expose the supporting evidence behind a classification instead of only showing a label. For example, users can inspect whether a visit looked like browser-backed traffic, a known preview fetch, automation, or something that still needs review, rather than just seeing a black-box score.
I think the biggest improvement we still need is making those explanations more human-friendly instead of exposing mostly technical signals. Thanks for calling that out.
I think that's a worthwhile tradeoff. Most people don't actually want more technical detail they want enough context to trust the decision they're making.
Maybe the default view is a plain-English explanation, with the underlying signals tucked behind an "Inspect" or "Why was this classified?" option. That gives marketers something actionable without hiding the evidence from technical users who want to verify it.
Have you found that early users actually open the technical breakdowns, or do they mostly stop once the explanation makes sense?
I agree. We're still early, so we're figuring out that balance.
Right now, LinksRF already shows the supporting signals and metrics when you drill into an analytics record.
As for usage, we don't have enough users yet to know how often people open the technical breakdowns, but that's definitely something we'll be watching
That’s probably the right thing to watch. A lot of early products assume users want more visibility, but the real signal is whether that visibility changes a decision they make.
The interesting metric might not just be “do users open the breakdown?” but “does seeing the evidence make them trust the data enough to take action?”
I’ve noticed with early tools, the hardest part is often separating features people appreciate from the parts that actually become part of their workflow. Finding that line early can shape the whole product.
Absolutely, I agree. That's actually the direction we're working towards.
It's less about whether someone opens the technical breakdown and more about whether the evidence gives them enough confidence to trust the data and make a decision. That's the outcome we ultimately want to measure.
that's a big reason I started building TaskRelay. I kept noticing that founders don't struggle because they lack data they struggle because there are dozens of small decisions and recurring tasks that pile up after the data comes in. My goal is to take those operational tasks off their plate so they can focus on the decisions that actually require their judgment. Your point about measuring whether evidence leads to action really resonates with that.
the trickier version of dlux's point: classification changes over time, not just per-request. a hit looks unclassifiable at t=0, but becomes obviously a bot once you see the same UA/IP hit the link 50 times in an hour. if a client already saw last week's report showing "confirmed engagement," does that number get silently rewritten once you reclassify, or does the report stay pinned to what you knew at export time? if it's the former, every report is provisional forever. if it's the latter, you need to snapshot the classification, not just compute it live.
That's a really good point, and honestly it's one of the harder product questions.
Traffic intelligence improves as more evidence becomes available, so classifications can become more confident over time. At the same time, silently rewriting historical reports would make them difficult to trust.
My current thinking is to separate historical snapshots from a live view. Reports should reflect what we knew at the time they were generated, while the live view can evolve as new evidence comes in, with a clear indication if a classification has changed.
This solves a real problem that exists in the gap between "we got clicks" and "we actually understand if those clicks matter." Most founders and marketing teams optimize for vanity metrics because they don't have access to the signal underneath.
The bet I'd validate: is this painful enough for enough teams to become their own analytics layer? Or does this end up as a feature request inside platforms that have distribution lock-in already?
The early signal will be which segment adopts first - growth teams tired of ambiguity, or content creators wanting to understand their audience. That'll tell you where the real pain is.
Thanks for the perspective. For me, the validation isn't whether it becomes a feature somewhere else it's whether teams start making better decisions because of it.
If people use LinksRF to investigate traffic spikes, separate real visitors from previews and automation, or explain campaign results with evidence instead of just click counts, then I think it's solving a real problem.
As for who adopts first, I'm keeping an open mind. Early users will tell me whether the strongest pain is with growth teams, agencies, or creators.
The interesting shift is moving from "how many clicks did I get?" to "what kind of traffic actually happened?"
What would convince you that traffic quality classification is painful enough for teams to adopt a dedicated product, rather than expecting it as a feature inside existing analytics platforms?
That's the hypothesis I'm trying to validate.
My belief is that traffic quality becomes its own product when it starts changing decisions, not just reports.
For example, if a marketing team sees 10,000 "clicks," that's interesting. If they can see that a meaningful portion was previews, automation or low-confidence traffic and understand why they can make different decisions about campaign performance, attribution and where to spend budget.
Existing analytics platforms are incredibly good at measuring traffic. I'm focused on helping answer a slightly different question of how much of that traffic can you actually trust?
If teams begin using that layer to investigate unusual spikes, compare campaign quality, or explain results to clients, then I think it earns its place as more than just another analytics feature. Time will tell, but that's exactly what I'm hoping to learn from early users.
Appreciate the context.
Would be good to continue the conversation as you learn whether teams start using that trust layer in their decisions.
What's the best email to reach you on?
I like that you are showing uncertainty instead of pretending every request can be classified perfectly. That would make me trust the numbers more. The useful view for me would be the evidence behind each bucket, not just the label. For example, why was a visit marked as likely human and what behavior moved it into confirmed engagement? Are you planning to let users inspect that reasoning when a campaign result looks unusual?
Thanks! That was one of the core design goals.
Rather than asking users to trust a single score, LinksRF lets them inspect the evidence behind each classification.
For example, on my current Product Hunt campaign, LinksRF captured 237 requests. Instead of reporting them all as "clicks," it categorized them into 159 real visitors, 41 preview fetches, 32 automated requests, and 5 visits that still needed review because the available evidence wasn't yet strong enough for a higher-confidence classification.
The idea is that users shouldn't have to trust a black-box result. They should be able to understand why something was treated as real traffic, preview activity, automation, or why it remained uncertain. We intentionally expose the supporting evidence while keeping the underlying detection model proprietary.