Feature feedback capture

Ask a targeted feedback question after a user has used a new feature twice — while the memory is fresh and the sample is qualified.

Use this when you have shipped a new feature and need real signal on whether it is landing before committing to more work on it. Don't use this when the feature has not shipped to enough users yet; the popup firing is cheap, but drawing conclusions from ten answers is not.

Goal

You ship a new section. Support is quiet, analytics shows some usage, and you have no idea whether users love it, find it confusing, or cannot find what they were looking for. Running a user-research round takes two weeks. This recipe drops a three-button popup on users who have engaged with the feature enough to have an opinion, captures the answer, and ships it to your analytics tool. You get a coarse but honest read in 48 hours.

Setup

In the dashboard

• Create a campaign new-section-feedback.

• Trigger: event NewSectionUsed with usage_count = 2.

• Conditions: new_section_feedback_given != true.

• Action: fire a deeplink to your in-app feedback popup, e.g. yourapp://popup/new-section-feedback. The popup asks "How's the new section?" with three buttons: "Love it", "Confusing", "Couldn't find what I wanted". See Custom popups for the popup-as-deeplink pattern.

• Each button tap is handled in-app: the app tracks the answer event and dismisses the popup. No further navigation.

• Frequency: once per user, ever — enforced by the new_section_feedback_given != true condition in the audience, not a native frequency cap.

In the app (engineering hand-off)

• Increment a usage counter and fire an event each time the feature is used:

  val count = currentCount + 1
  amply.setCustomProperty("new_section_usage_count", count)
  amply.track("NewSectionUsed", mapOf("usage_count" to count))

• On each popup button tap, track the answer and mark the user as answered:

  amply.track("NewSectionFeedback", mapOf("answer" to "love_it"))
  amply.setCustomProperty("new_section_feedback_given", true)

• Forward NewSectionFeedback to your analytics tool. That is where the team will read the split.

How it runs

1. User opens the new section for the first time. App increments the counter and fires NewSectionUsed { usage_count: 1 }. No campaign matches — the event trigger requires usage_count = 2.

2. Later that day, user opens the new section again. usage_count = 2. new-section-feedback matches.

3. Custom popup appears: "How's the new section?"

4. User taps "Confusing." App fires NewSectionFeedback { answer: "confusing" } and sets new_section_feedback_given = true.

5. The popup closes. The user continues using the app.

6. Over the next week, several hundred users answer. The product team reads the "Confusing" share in analytics and opens a ticket on whichever screen ranks worst for that cohort.

Metrics to watch

• Response-rate of the popup. A healthy range is 40-70%. Under that and the moment is wrong or the copy is off.

• Answer distribution. The absolute numbers matter less than the shape: "Couldn't find what I wanted" high means the information architecture is off.

• Correlation with retention. Do "Love it" responders have higher 30-day retention than "Confusing" responders? That is the test of whether the feedback is predictive.

• Time to first answer after feature launch. Fast feedback is the point of this recipe.

Related

• Custom popups — building the three-button popup

• Campaigns — event-triggered campaigns with usage-count conditions

• Tracking events — firing NewSectionUsed and NewSectionFeedback

• User attributes — marking new_section_feedback_given to prevent re-asking

• Feedback capture on negative rating — the rating-driven cousin of this recipe

• AI-assisted integration — describe this campaign in plain language and have your AI assistant build it