u/Dapper_Career4581

We all have that metric that stings: signed up, never came back.

I've been sitting on a hypothesis for a while and finally started testing it. The idea is simple — the problem isn't the question "why didn't you use it?" but the cost of answering it.

Currently, when you email an inactive user asking for feedback, you're asking them to:

Open email → Tap reply → Think of a reason → Turn it into sentences → Hit send

That's 5 steps. For someone who already doesn't care about your product, that's 5 reasons to close the tab.

So I'm testing: what if they could just tap a reason inside the email instead?

AMP email with 3-4 common reasons ("Setup felt too complex", "I don't need it right now", "I forgot about it") → one tap → done. No reply, no compose window, no friction.

The catch: Only Gmail/Yahoo/Mail.ru support AMP. But even reaching that subset with a lower-friction loop seems worth testing. For the rest, fall back to a short link and compare response rates.

I made a quick page to explain the concept and collect thoughts from founders who've dealt with this:

👉 askghost.dev/survey

Would love to hear:

- How do you currently handle inactive user feedback?

- What's your actual response rate on "we miss you" emails?

- Does this "choose instead of write" hypothesis hold water from your experience?

I've been learning computer vision and deep learning for a while now — nothing extraordinary, just my personal experience. Here are some practical tips I wish I knew when I started reading papers:

Get comfortable with set theory notation first

Before diving into papers, spend an hour on basic math notation — ∈, ∀, ∃, ⊆, ∪, ∩, and the common function mapping arrows (f: X → Y). Papers assume you're fluent in this language, and pausing to decode every symbol kills momentum.

Don't get stuck on equations — read through first

You'll hit formulas that look like alien scripture. Trust the authors. They've already verified their proofs (often in the appendix) and run experiments to back their claims. Read the sentence as-is, accept it provisionally, and finish the whole paper before circling back. Understanding deepens with context, not with staring harder.

Always identify input and output shapes

This is the single most useful habit I've developed. Before worrying about the fancy architecture in the middle, write down: what is the input tensor shape? What is the output tensor shape? For example, an MNIST classifier → input is (N, 28, 28, 1), output is (N, 10). Everything in between is just a transformation pipeline connecting these two. This alone demystifies 80% of papers.

Read the code — every line (if available)

Open-source code is the real paper. The paper tells you the story; the code tells you what actually happened. When you want to combine ideas from multiple papers into your own model, you need to know how to implement them. The ability to translate equations into code is the skill that compounds over time.

Start with the classics — even if they're "old"

R-CNN, U-Net, ResNet, YOLO — they're easier to understand, have tons of explanations written by others, and give you a confidence boost when you actually get them. Modern papers are often combinations of building blocks from these classic works, so you'll end up chasing their references anyway. Build the foundation first.

Avoid mathematically dense papers too early

WGAN, SNGAN, neural ODEs — these go deep into theory and can crush your self-efficacy if you hit them too soon. (If you're strong in math, ignore this. But for the rest of us... save them for later.)

Learning is stair-shaped, not linear

You'll plateau for weeks, then suddenly jump. Then plateau again. This is normal. Don't quit during the plateau.

Hope this helps someone starting out. What tips would you add from your own experience?

I'm testing a hypothesis about inactive user feedback — and I'd love your input

Tips for beginners reading CV/AI papers (from someone who's been through it)