A practical engineering approach to interaction-aware ad suppression

⸻

Why This Problem Matters

In many mobile applications, ads are inserted based on screen placement or timing rules, without considering what the user is actively doing.

From an engineering perspective, this creates several problems: • Ads appear during transactional or repetitive actions • UI performance degrades during high-frequency updates • Monetization logic becomes tightly coupled with UI flows

While building a production mobile application, we observed that the issue wasn’t which ads were shown — it was when they were shown.

This led us to implement an interaction-aware ad suppression system that treats monetization as a runtime decision based on user interaction state.

This post focuses on the engineering side of that system.

⸻

Tracking Interaction Events

The first step is capturing meaningful interaction signals locally.

Examples of events we track: • Screen transitions • Button confirmations • Rapid repeated inputs • Pauses or idle periods

Rather than reacting to individual events, we group them into short time windows and evaluate them as sequences.

This avoids overreacting to noise while still capturing user intent.

⸻

Deriving Interaction States

From these event sequences, the application derives a small set of interaction states, such as: • Task-execution state Active workflows or transactional actions • Navigation state Screen changes and exploration • Review state Pauses, confirmations, or summaries • Idle state Low or no interaction

Each state has different tolerance for interruption.

For example: • Task-execution → ads suppressed • Review / idle → ads may be allowed

This keeps the decision logic explicit and explainable.

⸻

Suppression-by-Default Logic

A key design decision was to suppress ads by default.

Instead of trying to detect every possible “bad” moment, the system assumes ads are disabled unless explicitly permitted by the current interaction state.

This approach: • Simplifies decision rules • Prevents accidental interruptions • Reduces edge cases

From an engineering standpoint, it also minimizes unnecessary UI re-renders and network calls during critical workflows.

⸻

Local Decision-Making

All interaction state evaluation happens on-device.

The client application: • Determines the current interaction state • Decides ad eligibility • Records basic post-delivery feedback

Remote services, if used, are limited to: • Aggregation • Auditing • Offline analysis

They are not part of the real-time decision path.

This improves latency, reliability, and behavior under poor network conditions.

⸻

Lightweight Feedback, Not Over-Optimization

After an ad is shown (when allowed), the system observes simple signals: • Immediate dismissal • Continued workflow • No interaction

These signals are used to adjust thresholds gradually, not to aggressively optimize delivery.

The goal is stability, not maximization.

⸻

What Worked Well in Practice

From an implementation standpoint, this approach resulted in: • Cleaner separation between UI and monetization logic • Fewer performance regressions • More predictable application behavior • Reduced user disruption

Most importantly, the system aligned monetization behavior with actual user interaction patterns.

⸻

Final Thoughts

Ads don’t need to compete with user workflows.

By treating monetization as an interaction-aware engineering problem, rather than a purely revenue-driven feature, applications can remain sustainable without sacrificing reliability or trust.

Sometimes the best decision a system can make is not acting at all.

⸻

About the Author

Pradeep Kumar Jalakam is a software engineer and product builder working on scalable, mobile-first applications with a focus on system design, performance, and responsible monetization.