Discussions

I am working on the early product design for a mobile app that helps users discover and organize AI tools.

The web version already covers products across categories such as writing assistants, image generators, video tools, transcription services, coding assistants, research platforms, marketing software, productivity tools, and workflow automation. The mobile app would not simply reproduce a directory in a smaller screen. The goal would be to help users find useful tools for a specific task, save them, compare alternatives, and return when they have another problem to solve.

I am trying to think through the mobile engagement and retention system before implementing it.

The difficult part is that this is not a product people necessarily need every day. A user may open the app when they need a transcription tool, save two options, visit one product, and then disappear for several weeks. Sending generic daily notifications would probably create annoyance rather than retention.

I would like to design a lifecycle that responds to genuine product intent instead of pushing users simply because they have been inactive.

The Core User Journey

The basic journey currently looks like this:

1. A user installs the app.
2. They choose one or more interests during onboarding.
3. They browse a category or search for a task.
4. They open several tool profiles.
5. They save, compare, or visit one of the tools.
6. They may return later to look for another category.

The first question is how much information to request during onboarding.

I could ask users to choose roles such as:

• Developer
• Marketer
• Designer
• Content creator
• Student
• Small business owner
• Researcher

I could also ask what they want to accomplish:

• Write or summarize content
• Generate or edit images
• Create videos
• Transcribe audio
• Build software
• Automate repetitive work
• Conduct research
• Improve marketing workflows

However, a long onboarding flow may delay the moment when users actually see useful products. My current thought is to ask for only one primary goal, allow the user to skip, and infer the remaining interests from browsing behavior.

Would this be enough to personalize the initial experience, or would role and task selection both be worth collecting?

Events I Am Considering Tracking

I want to avoid collecting events that will never influence a product decision. The initial mobile SDK event model might include:

app_opened
onboarding_started
onboarding_completed
interest_selected
category_viewed
search_performed
tool_profile_viewed
tool_saved
tool_unsaved
comparison_started
external_tool_link_opened
notification_opened
notification_dismissed

Possible event properties could include:

category
search_query
tool_id
tool_type
user_role
selected_interest
traffic_source
session_number
days_since_install

The website behind the project is best ai tools , so the relevant product semantics include AI tool discovery, software categories, writing assistants, image generation platforms, AI video creation, audio transcription, coding utilities, marketing automation, productivity software, research tools, and workflow applications.

I do not plan to store the content users create inside third-party tools. The app would mainly track discovery behavior inside our own product: what categories users explore, which listings they save, which comparisons they start, and which external product pages they choose to visit.

My concern is whether external_tool_link_opened should be treated as the main activation event.

It shows strong intent, but it also sends the user out of the app. A user who finds a useful product and leaves may have received full value even if they do not return soon. Measuring retention alone could therefore make a successful session look like failure.

Would it make more sense to define activation as one of the following?

• Saving at least one tool
• Viewing three tool profiles in the same category
• Starting a comparison
• Opening an external tool website
• Completing any two of the above

Segments I Would Like to Build

The initial user segments might include:

New users with no meaningful action

Users who completed or skipped onboarding but did not search, browse a category, save a tool, or open an external listing.

Possible response:

• Show a simpler home screen on the next session.
• Recommend three popular categories.
• Avoid push notifications until the user demonstrates interest.

Category explorers

Users who viewed several products within one category but did not save or open anything.

Possible response:

• Show a comparison prompt.
• Suggest filtering by price, platform, or use case.
• Continue the category from the previous session.

High-intent evaluators

Users who viewed several profiles, saved products, or started a comparison.

Possible response:

• Offer a saved-tool collection.
• Notify them only when a saved product receives a meaningful update.
• Suggest alternatives within the same category.

One-time successful users

Users who opened an external product page but did not return.

This group is difficult. They may have found exactly what they needed, so an aggressive re-engagement sequence would be inappropriate.

A possible message after a reasonable delay could focus on a related task rather than asking them to come back generically.

For example, someone who explored transcription tools might later receive a suggestion about subtitle generation, meeting summaries, podcast transcription, or audio cleanup.

Repeat category users

Users who repeatedly search within the same area, such as coding or image generation.

Possible response:

• Personalize the home feed around that category.
• Allow alerts for newly added or updated products.
• Reduce unrelated recommendations.

Multi-category users

Users who regularly explore different kinds of software.

Possible response:

• Send a weekly digest rather than individual alerts.
• Emphasize saved collections and recent discoveries.
• Recommend workflow combinations across categories.

Are these segments too behavioral and narrow for an early-stage app? Would it be better to begin with only three groups: new, activated, and returning?

Push Notification Strategy

I do not want to send notifications such as:

Come back and discover more AI tools.

That message gives the user no reason to open the app.

I am considering notifications only when there is a clear connection to prior behavior.

Examples:

Saved-product update

A tool you saved has added a new export option.

Category update

Three new transcription tools were added to a category you follow.

Unfinished comparison

You saved two image tools but did not compare their pricing and export limits.

Useful related workflow

You explored audio transcription. These tools can also turn transcripts into summaries and subtitles.

Weekly digest

New tools this week in coding, research, and automation.

The notification system would need frequency limits. My initial idea is:

• No more than one behavioral notification within 72 hours.
• No more than two push notifications per week.
• Immediate notifications only for explicitly followed tools or categories.
• Stop re-engagement messages after two ignored notifications.
• Allow users to choose categories and notification frequency.

I am unsure whether a seven-day inactivity trigger is appropriate. For a utility discovery product, normal usage may be irregular. Fourteen or thirty days may better reflect the natural return cycle.

How would you choose the inactivity window without having historical retention data?

Onboarding Experiments

I am considering several A/B tests.

Experiment 1: Immediate browsing vs. interest selection

Variant A: Open directly to the tool feed.

Variant B: Ask the user to choose one primary task before showing recommendations.

Primary metrics:

• First-session category views
• Tool-profile views
• Saved tools
• External link opens
• Day-7 return rate

Experiment 2: Role-based vs. task-based onboarding

Variant A: “What do you do?”

Variant B: “What are you trying to accomplish?”

My assumption is that task-based onboarding will perform better because a person may have several roles but usually installs the app with one immediate problem.

Experiment 3: Save prompt timing

Variant A: Show the save feature immediately.

Variant B: Explain saving after the user views a second tool profile.

The second variant may create more context, but it may also hide an important retention feature.

Experiment 4: Notification permission timing

Variant A: Ask during onboarding.

Variant B: Ask only after the user saves a tool or follows a category.

I strongly suspect Variant B will produce fewer permission requests but higher-quality opt-ins.

Would you use notification opt-in rate as the primary metric, or should it be evaluated together with later notification opens and disable rates?

Retention Metrics

Standard Day-1, Day-7, and Day-30 retention may not fully describe this product.

I am considering measuring:

• Time to first meaningful action
• Percentage of users who view three or more relevant tool profiles
• Save rate
• Comparison-start rate
• External-link-open rate
• Return rate after saving a product
• Return rate after following a category
• Notification open rate
• Notification disable rate
• Number of successful discovery sessions per user
• Percentage of sessions ending in a saved tool or external visit

A “successful discovery session” could be defined as a session where the user saves a tool, compares products, or opens an external product page.

This may be more useful than optimizing session duration. Ideally, users should be able to find an appropriate product quickly rather than remain inside the app for a long time.

Questions for People With Mobile Engagement Experience

I would appreciate advice from anyone who has designed onboarding, analytics, segmentation, push notifications, or lifecycle automation for utility apps, directories, marketplaces, or products with irregular usage.

My main questions are:

1. What would you use as the activation event for this kind of app?
2. Is opening an external product page a successful conversion, even though it ends the session?
3. Which events would you remove from or add to the initial tracking plan?
4. How many behavioral segments are reasonable before there is enough user volume?
5. How would you determine a suitable inactivity window for push notifications?
6. Should onboarding ask about a user’s role, immediate task, or neither?
7. Which A/B test would you run first?
8. Are there privacy or analytics-design issues in this event model that I may be overlooking?
9. How would you distinguish useful re-engagement from notification spam in a product that users may only need occasionally?

I am particularly interested in practical implementation advice: SDK event structure, user-property design, event naming, segment rules, notification frequency caps, onboarding experiments, and metrics that would help distinguish genuine product value from superficial engagement.

The goal is not to maximize the number of app opens. It is to help users find an appropriate tool when they have a real task, and then give them a credible reason to return when another relevant need appears.