Explore

PRD - Ads takeover on PTS

⁠

Screenshot 2025-05-27 at 10.46.47 AM.png

⁠

Objective

Transforming the payment transaction screen into high-value ad real estate, unlocking a ₹2Cr+ monthly revenue opportunity by enabling brands to reach 31Mn DAU through targeted 8-10 day roadblock campaigns

Success metrics

While ad revenue remains the north star, changes will be implemented with transaction integrity in mind, while also enhancing ad engagement and supporting our strategy to diversify revenue and expand ad-tech capabilities. Details –

Goal

Metrics

[P0 Northstar] Improve ad revenue by monetizing PTS as a prime ad real estate

Net ad revenue

Ad revenue per successfully transacting user

Ad coverage - % ad filled slots, of overall successful transactions

[P0 /Supply shaping] Maximize ad engagement and optimize top-performing formats / advertisers for supply shaping

Ad conversion funnel (Impressions → Views → Clicks)

Advertiser conversion funnel

Advertiser eCPM - Revenue earned per 100 impressions

[P1 / Check] Maintain seamless transaction experience while integrating ads

Relevant transactions per user

Payment screen drop off

User retention post ads

There are no rows in this table

⁠

Assumptions

Implementing a fit-to-size layout on Android is complex and might require creative ops support to handle variable aspect ratios, leading to higher costs.

To accelerate deployment, we will support static image banner ads using existing SF widget capabilities

Milestones

Product solutioning - Done

Design solutioning - Done

Tech grooming - Setup for Mon Mar 17, 2025

Tech solutioning closure - Mar 28th

Launch - v10.58.0 (May W2)

Requirements

Requirement

User Story

Importance

Jira Issue

Notes

Ad design has to be edge to edge on PTS landing screen through dynamic size responsiveness / shutter box in ad ambient colors

As a user, I want a smooth post-transaction experience with engaging, non-disruptive ads.

HIGH (v1)

Handling low internet connectivity

The system must gracefully handle scenarios where users have low internet connectivity

HIGH (v1)

Logging ad interactions in-house pulse interactions, alongside DCM and Appsflyer, for seamless tracking and data reconciliation with advertisers

As an advertiser, I want a transparent view of campaign analytics, including impressions, views, and clicks.

HIGH (v1)

PTS ads should fully integrate with existing Ads Manager capabilities for seamless ad operations.

As an Ads Ops rep, I want PTS ad support without any changes to the existing ad manager or campaign setup workflow (Both roadblock and segmented roadblock)

HIGH (v1)

All other storefront widgets will be pushed below this ad and the user can only view those widgets post scrolling down

As a user, I want to retain ability to access my passbook and other default actions at transaction screen

MEDIUM (v1)

Call-to-action (CTA) buttons will be integrated into the card to guide users towards further actions

As a user, I want seamless options to mute / unmute ads via dedicated CTAs.

MEDIUM (v2)

To be parked for v2 / Video ads

There are no rows in this table

⁠

User interaction and design

VDs indicating user’s interaction with PTS ads

(v1) GIF / Static ads

⁠

https://www.figma.com/design/t33gQ5lYQCMtUd2stg4pwe/New-Post-Payment?node-id=1402-14580&p=f&t=31h83w09TqrMSyC1-0⁠

⁠

Video / Animation ads - TBP v2

Reference / outside IN -

⁠

https://docs.google.com/presentation/d/17-ivP-BGThuViznDa1JMECcseiIopAPnx2_xDqi1h9M/edit#slide=id.g31bb5c45396_4_30⁠

⁠

Tech solutioning details -

E2E rendering - Recommending Approach 1. Details -

⁠

Device level aspect ratio / screen size distribution⁠

Table 4

Table 4

Approach

Pros

Cons

Tentative dev effort (Excl. QA and E2E testing)

Release timeline

Approach 1 - Standard aspect ratio with fixed width and variable heights

Faster implementation with minimal backend changes

Scalable for most devices and transaction pages

Banner might stretch / need ambient padding for long tail devices

PTS FE -

SF FE - S (5 days)

Ads tech BE - S (4 days)

App version 10.58.0 / May W1

Approach 2 - Variable aspect ratio optimized for key screen sizes

Improved rendering for commonly used devices

Requires significant backend development to manage multiple creatives

Higher operational and creative effort to design various aspect ratios

Potential quality compromises for non-standard screen sizes

PTS FE -

SF FE -

Ads tech BE -

SF BE -

TBU

Approach 3 : Hybrid - Variable aspect ratio for key devices + Fixed fallback for others

Ensures better rendering for key devices while maintaining scalability for others

Longer development timeline due to changes in ad backend, widget serving, and storefront systems

PTS FE -

SF FE -

Ads tech BE + FE -

SF BE -

TBU

There are no rows in this table

⁠

Requirement repository -

Ads BE (

Jitendra Singh Bisht⁠

Sharma Kamal5⁠

)

The newly onboarded widget/view ID should be mapped under the Post Payment Transaction page in Ads Manager as Widget/RO Type → Roadblock

PTS widgets should support campaign setup via Ads Manager while retaining instrumentation and 3P ad tracking capabilities

Ads BE - FE handshake (

Ram Chauhan⁠

)

No changes in how creatives or applicable campaigns are served to FE

SF BE - (

VisheshTyagi⁠

BhaveshRandhir⁠

)

Implement a filtering logic to serve only the roadblock banner and floating bottom nav when a roadblock campaign is active, blocking other upsell widgets

Check if this can be config-managed to enable future support for additional roadblock widgets on PTS

Ensure campaign setup, including cohort and experiment duration, is managed through Ads Manager

SF / PTS FE - (

Marali, Dhanyaraja⁠

)

Support both static images and GIFs for roadblock banner rendering

Optimize edge-to-edge rendering for ~90% of devices, minimizing white space and ensuring a scroll-free experience wherever possible

Handle white spaces, if required through ambient color padding

Maintain BAU page load and latency despite these updates

Out of Scope

v1 covers only successful P2P and P2M payment transactions on native Android/iOS through static / GIF ads

Mandate and IPO cases are excluded from v1 as they run on HTML5

Rich media phasing -

Phase 1 - Support for static banner / GIFs via existing SF widgets

Phase 2 - Support for Lottie animation / Videos

JIRA -

⁠

CA-249292⁠

- SF Android

⁠

CAI-102171⁠

- SF iOS

⁠

CATSF-3297⁠

- SF BE

⁠

AT-16163⁠

- Ad tech BE

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.