01 - Background
Search is the front door. We were leaving money at the step.
By 2024, Pathao Food had grown to 500,000+ active users across Bangladesh and Nepal. For the majority of them, the search bar was how they used the app - not category browsing, not homepage scrolling. When someone opened Pathao Food hungry, they typed what they wanted. That made the search result list some of the most valuable real estate in the entire product.
But we were treating that real estate like a free public park. Our search ranking was purely organic: restaurants were surfaced based on name matching, cuisine tags, and fuzzy search - no monetisation layer at all. The only semi-commercial mechanism was a blunt "Featured" tag that gave a restaurant a broad visibility boost across all searches, regardless of what the user actually typed.
Every food delivery platform at scale - Swiggy, Zomato, foodpanda - had already built keyword-based monetisation into their search. Restaurant partners expected it. We were behind.
Revenue Gap
Commission was our only lever
Pathao Food earned exclusively through order take-rate. Revenue moved with demand. We had no recurring, predictable non-commission income stream - and no product to offer partners who wanted visibility, not just order-dependent returns.
Partner Pain
Great restaurants stayed invisible
Strong restaurant partners with poor tag coverage ranked below lesser ones. No structured way to invest in visibility. The only option - Featured - had no keyword precision: it surfaced you for every search, not the right ones.
Data Gap
Intent signals, completely untapped
30 days of search logs sat in BigQuery - every keyword, frequency, conversion outcome, broken down by city and zone. We had a detailed map of what users wanted. We just weren't using it to drive anything.
02 - Problem
A monetisation problem and an integrity problem - inseparable.
The obvious move was to let restaurants pay to rank higher. But doing that naively would break the one thing that made search valuable in the first place: users trust that results are relevant. The moment a user searches "Biryani" and the top result is a burger place that bought their way there, they lose faith in the whole system. Broken trust means fewer searches, fewer clicks, fewer orders - and ultimately less value for the paying restaurants too.
The core question I had to answer
How do you monetise search ranking without making it feel like results are for sale? The answer had to protect user trust and deliver partner ROI at the same time. Solving only one would make the other worse.
The business side was clear: restaurant partners wanted keyword-specific placement, not a one-size-fits-all "Featured" tag. They wanted to pay to rank for "Kacchi Biryani" in Gulshan - not to appear for every search across the city. They wanted measurable ROI: orders, footfall, contract terms they could plan around.
The integrity side was equally clear: if a restaurant could self-select any keyword they wanted, quality would collapse quickly. A new pizza place would buy "Biryani." A coffee shop would buy "Chicken." Relevance would be gone within a month of launch. So the core constraint I designed the whole system around was this: restaurants cannot choose their own keywords. Keywords must be assigned by data science based on actual user search behaviour.
Must solve - Business
A monetisable visibility product for partners
Keyword-specific placement. Two clear tiers with predictable ranking positions. Contract-style start/end dates so revenue is recurring and forecastable, not just transactional. A sales team must be able to pitch it clearly.
Must solve - Trust
Keep organic results relevant
Paid results should only activate when they're genuinely relevant to the query. DS-assigned, data-driven keywords. Restaurants cannot game the system. Paid positions must be transparent - users should be able to see commercial status without being alienated by it.
03 - Who It Affects
Two different stakeholders, one shared interest in search quality.
This was a two-sided product. I had to design for restaurant partners (the paying customers) and end users (the people searching) simultaneously. Getting either side wrong would undermine the other.
🍽️
The Restaurant Partner
KFC, local biryani chains, premium casual dining
Goal
Drive orders and footfall in specific areas. Justify the investment with measurable ROI.
Pain
Good food, poor discoverability. Paying commission on every order but no way to invest in visibility. "Featured" too blunt - shows up everywhere, ranks for nothing specifically.
Need
To rank at the top when a user in their area searches for exactly what they sell - and see the data to know it's working.
🔍
The App User
500K+ users searching for food in BD & Nepal
Goal
Find food they want, quickly. Trust that results reflect what the platform knows about quality and relevance - not who paid more.
Pain
Any hint that results are "bought" erodes confidence. Already sceptical of promoted content from other platforms.
Need
Relevant results first. Commercial signals that are transparent, not hidden - so they can make an informed choice rather than feeling deceived.
04 - My Approach
Three interlocking decisions that had to hold together.
My approach centred on three design decisions that were mutually dependent. Remove any one of them and the system breaks down.
1
Let data assign keywords, not restaurants
I worked with our DS team to build a keyword inventory from 30 days of real search logs - city by city, zone by zone. Every keyword came with two scores: how often users search it, and what percentage of those searches convert to an order. DS then assigns up to 10 relevant keywords to each partner restaurant based on their cuisine and menu. The restaurant never touches this. This single decision is what makes the whole paid system trustworthy.
2
Insert paid tiers into the existing ranking with fixed positions
Rather than a real-time auction (which would require complex infrastructure and could still produce irrelevant results), I designed two fixed tiers - Signature (P2) and Select (P3) - that slot directly into the ranking hierarchy above Featured. Position is deterministic: if you hold Signature and a user searches for one of your assigned keywords, you rank at P2. No bidding, no uncertainty. Simple to sell, simple to operate, easy to QA.
3
Make commercial status visible, not hidden
Paid restaurants display a badge beside their name everywhere in the app - a gold star (★) for Signature, a blue diamond (◆) for Select. Users can see that these are partners. This is the opposite of dark-pattern advertising: transparency protects trust better than concealment does. It also signals to users that a badged restaurant has passed Pathao's threshold for paid partnership, which itself carries a quality implication.
Why not an auction model? Auction-based search (like Google Ads or Zomato Promoted Listing) requires a bidding interface, real-time infrastructure, and complex ops workflows. At our scale and operational maturity in 2024, that complexity was the wrong trade-off. Fixed tiers that ops can manage from a dashboard were simpler to build, simpler to sell, and far less likely to produce relevance-destroying outcomes from aggressive overbidding. The simple system shipped. The complex one would have spent six months in architecture discussions.
05 - Ranking Design
Nine levels. Every position a deliberate choice.
I expanded the existing search ranking from 6 priority levels to 9, inserting the two paid tiers above Featured while preserving the rule that direct name matches always win. The full hierarchy is deterministic - each position is defined by restaurant status, not by score. Ties within the same priority level break by name length first, then alphabetically. This makes the ranking fully auditable and easy to QA with a single worked example.
P1
Exact Name MatchUser typed the restaurant's full name. Always wins, regardless of any paid status. If someone searches "Star Chicken," Star Chicken is first. Non-negotiable.
Organic
P2
Pathao Signature ★Premium paid tier. Only activates for keywords DS has assigned to this restaurant. Gold star badge visible throughout the app. Highest commercial position available.
Paid
P3
Pathao Select ◆Standard paid tier. Same DS-assigned keyword logic as Signature. Blue diamond badge. Ranks below Signature but above Featured and all organic positions.
Paid
P4
FeaturedLegacy broad-visibility tier. Shows up elevated across all searches regardless of keyword. Mutually exclusive with Signature and Select - a restaurant can't hold both.
Organic
P5
Name Prefix MatchRestaurant name starts with the search term. "Chicken King" for a query of "Chicken."
Organic
P6
Auto-Generated TagsSystem-derived tags from restaurant name and profile. Applied by the platform, not restaurants themselves.
Organic
P7
Primary Cuisine TagThe main cuisine classification manually set by Food Ops. Strong intent signal.
Organic
P8
Secondary TagsSupplementary cuisine tags. Broader classification, used as fallback when primary doesn't match.
Organic
P9
Fuzzy MatchApproximate matching for typos and Banglish input. Last resort. "Chickn" still finds "Chicken" restaurants.
Organic
How this plays out in practice
I documented a canonical worked example in the PRD so every team - backend, DS, QA, design - had the same mental picture of what correct ranking looks like. Here's the "Chicken" query with all tiers represented:
User types into search bar
🔍 Chicken Dhaka · paid packages active
1
Chicken (a restaurant literally named "Chicken")
P1 · exact name
2
Star Chicken ★
P2 · Signature · keyword match
3
Fry Restaurant ★
P2 · Signature · keyword fuzzy match
4
Hot Chicken ◆
P3 · Select · keyword match
5
BFC
P4 · Featured
6
Chicken King
P5 · name prefix
7
CP Chicken-3
P6 · auto-tag
8
KFC
P7 · primary tag: chicken
9
Chickn Fried Restaurant
P9 · fuzzy match
Why this worked example mattered: Having one canonical, human-readable QA scenario eliminated most of the ambiguity around ranking behaviour. The QA team ran this exact query in staging to validate all 9 levels. When a ranking anomaly was reported post-launch, the first debugging step was always: "Does the Chicken example still behave correctly?" A concrete example catches more spec gaps than three pages of abstract rules.
06 - Keyword System
The engine that keeps paid results relevant.
The keyword system is what separates this from pay-to-win. It's entirely owned by our data science team - restaurants have no input into their keyword list. I worked closely with DS to define how keywords are generated, scored, assigned, and maintained over time.
Keywords ≠ Tags: Tags (auto-tags, primary, secondary cuisine tags) are organic ranking signals used for all restaurants. Keywords are paid activation triggers - they determine which searches cause a Signature or Select restaurant to boost their position. They're separate systems that look similar but serve completely different functions. I documented this distinction explicitly early on because ambiguity here caused team confusion in early planning.
How keywords are built and maintained
Step 1 - Generate
Mine 30 days of real search behaviour
DS pulls the last 30 days of search queries from BigQuery, partitioned by city and zone. Each keyword gets two scores: Search Frequency (how many users type this) and Conversion Rate (what % of searches for this term result in an order). The 30-day rolling window keeps the inventory seasonal and current without being noisy.
Step 2 - Assign
DS maps relevant keywords to each restaurant
For each restaurant entering a paid tier, DS assigns up to 10 keywords from the city/zone inventory that genuinely match what that restaurant serves. A biryani house gets biryani-related keywords. A burger chain gets burger-related keywords. No exceptions. High conversion-rate keywords are prioritised because they drive actual orders, not just impressions.
Step 3 - Manage
Active/inactive states, never delete
Keywords can be deactivated but not deleted. A seasonal keyword like "Iftar platter" goes inactive after Ramadan and reactivates the following year without rebuilding. This keeps the inventory growing while maintaining a clean working view for ops agents, who only see active keywords in their screens.
The conversion rate score was a deliberate design choice I pushed for. Search frequency alone would bias the system toward broad, low-intent queries like "food" that don't actually drive orders. A keyword with moderate frequency but high conversion rate is far more valuable to a restaurant partner - and it represents a genuinely useful signal, not just noise. DS used this two-signal scoring to build an inventory that serves partner ROI, not just visibility metrics.
07 - Paid Tiers
Two tiers. Fixed positions. No auction, no ambiguity.
I designed two system-level tiers - fixed constants that no ops agent or restaurant can modify. The simplicity was intentional: a sales team needs to pitch two clear products, not explain a configurable menu of options. The ranking position of each tier is deterministic, making the product easy to understand and easy to demonstrate ROI for.
★
Pathao Signature
The premium tier. Ranks immediately below exact name match - P2 in the search hierarchy. Above all paid and organic results including Featured.
Ranks at P2 - only an exact name match outranks this
Gold ★ badge shown beside restaurant name everywhere in the app
Up to 10 DS-assigned keywords, scoped to city and zone
Requires a defined start date and expiry date - both mandatory
Cannot be combined with Select or Featured at the same time
Package updates take next working day; removal is immediate
◆
Pathao Select
The standard paid tier. Ranks above Featured and all organic results for matched keywords. P3 in the search hierarchy.
Ranks at P3 - below Signature, above Featured and organic
Blue ◆ badge shown beside restaurant name everywhere in the app
Same 10-keyword limit and zone scoping as Signature
Same mandatory start/expiry contract model
Cannot be combined with Signature or Featured
Package name locked post-assignment to preserve billing audit trail
Why mutual exclusivity mattered: If a restaurant could simultaneously hold Signature, Select, and Featured, it would occupy P2, P3, and P4 in a single search - squeezing out three organic positions for a single partner. This creates an arms-race: big chains buy all tiers, smaller partners get pushed further down regardless of keyword relevance. One active package at a time was a fairness constraint built into the architecture, not just a billing simplification.
Contract lifecycle rules
I designed a set of contract rules that made the system auditable, prevented misuse, and let the Food Ops team manage the programme without engineering involvement for routine operations.
Future-dated contracts only: Both start and expiry must be set to future dates when a package is assigned. Prevents backdating to claim visibility credit for prior periods - an audit-trail protection that matters when billing disputes arise.
Updates next working day, deletions immediate: Changes to a package take effect overnight via batch processing, which prevents real-time race conditions. But if a contract needs to be cancelled, the removal is instant - so billing disputes can be resolved cleanly without the partner showing as "paid" for another 24 hours.
Package name locked once assigned: You can update keywords, dates, and other fields, but you can't change "Signature" to "Select" on an existing record. If you need to change tier, you delete and re-create. This keeps the audit trail clean and billing records unambiguous.
08 - User Experience
Transparent signals, not hidden promotions.
The UX philosophy I applied here was transparency over concealment. Users should be able to see which restaurants are commercial partners. Not buried in fine print - visible, ambient, and consistent. This mirrors how Google, Swiggy, and other mature platforms handle promoted placements: a clear signal that informs choice rather than manipulating it.
Badge design - Signature ★ and Select ◆
Paid restaurants display their tier badge beside their name on every surface in the app: search results, restaurant cards, collection pages, and the Food Ops dashboard. The badge is tied directly to the active package record. When a package expires or gets removed, the badge disappears automatically across all surfaces - no manual ops intervention required. I made this an explicit functional requirement because a stale badge after a contract ends is a trust problem.
Signature ★ Gold Star
Premium partner status, visible everywhere
Shown in search results, restaurant cards, collection tiles, and the ops dashboard. The gold star is familiar enough across platforms that most users will correctly infer "premium partner" without needing an explanation. Disappears immediately when the Signature package is removed or expires.
Select ◆ Blue Diamond
Standard partner status, clearly differentiated
Same surface rules and auto-expiry behaviour as Signature. The two badges are visually distinct by design - a savvy user who sees both understands the hierarchy (★ outranks ◆) without us explaining the tier system. Mutual exclusivity means no restaurant ever shows both.
Popular Searches dropdown
When a user taps the search bar before typing, they see a "Popular Searches" list of up to 10 paid keywords. These rotate randomly from all active keywords in the user's city - so over time, users encounter the full breadth of what's available, not just the most-purchased keywords. City-level filtering ensures a Dhaka user never sees Chittagong-specific suggestions.
Why random rotation instead of ranking by keyword value? If we sorted Popular Searches by how much each keyword earned, only the highest-value keywords would ever be seen. That would create a secondary visibility auction inside the dropdown, penalising mid-tier partners who bought keywords but couldn't outbid the major chains for the dropdown slots. Random rotation distributes discoverability more fairly across all paying partners.
Analytics: closing the ROI loop
I specified two key events to instrument alongside this feature. The first fires when a user taps a keyword from the Popular Searches dropdown - telling us which keywords are actually driving search sessions. The second fires when a user taps any Signature or Select restaurant in search results - giving us direct attribution from paid placement to a click, which can then be joined with order data to show restaurant partners their actual ROI. Without these events, we'd be selling visibility with no way to prove it worked.
Search inside Collections
The paid ranking logic was extended to apply inside Collections search as well - not just global search. If a user searches "Biryani" inside a "Ramadan Specials" collection, the same priority hierarchy applies. This was important for restaurant partners who invest in collection placement alongside paid search. Their Signature or Select status should work consistently wherever search appears in the app, not just on the main search screen.
09 - Ops Tooling
A commercial product is only as strong as the ops team's ability to run it.
The user-facing experience was relatively simple - two badges, one dropdown. But behind it was a set of daily workflows the Food Ops team would need to run without engineering involvement for every operation: onboarding partners, assigning keywords, managing packages, tracking expirations, handling disputes. I designed four dashboard screens to make this self-serve from day one.
S-D-1
Keyword Assignment Screen
The primary onboarding screen. When a restaurant partner signs a package, the ops agent comes here to assign their keywords. Shows available active keywords sorted by click rate and conversion rate (highest first), so agents are nudged toward assigning the most impactful keywords. The 10-keyword maximum is enforced at input. Existing assignments can be updated or removed. This is the most-used screen in the daily ops workflow.
S-D-2
Keyword Inventory View
A read-heavy reference screen showing the full keyword inventory for a selected city and zone. City and zone must be selected before the list loads - a hard gate that prevents cross-zone data from appearing in the wrong context. Each keyword shows its conversion rate, search frequency, and last update date. Sortable by all columns. Used by DS and senior ops to review keyword quality and by agents who want to check whether a keyword is still active before assigning it.
S-D-3
Search Dropdown Config
Controls the "Popular Searches" experience in the user app. Ops can see how many active keywords exist per city, which determines whether the dropdown shows at all (minimum 10 required). City-level filtering is applied here, ensuring users only see keywords relevant to where they are. A simple config screen but a critical operational checkpoint - if a city drops below 10 active keywords, the team needs to know before the dropdown disappears for users.
S-D-5
Package Management Table
The contract management heartbeat of the commercial programme. Lists all restaurants currently on a paid package, showing: restaurant name, package tier, tagged keywords, start date, expiry date, and action buttons (update / delete). Default sort is by upcoming expiry date - soonest expiry at the top. This single UX decision means the ops team, opening this table each morning, immediately sees which contracts need renewal attention today without having to filter or hunt. Supports search by restaurant name and paginated loading for large partner lists.
Phase 1 scope decision: The ops dashboard was originally scheduled to ship in full with Release 1. Due to bandwidth constraints, I made the call to prioritise S-D-1 and S-D-2 first - the screens blocking commercial launch - and defer S-D-5 to the next sprint. Documenting this explicitly in the PRD prevented the ops team from planning workflows around a screen that wasn't available yet, and gave engineering clear sequencing criteria to work against.
10 - Go-to-Market
Phased validation before touching what 500K+ users see.
Modifying search ranking for a product at this scale carries real risk. A ranking bug at launch could surface irrelevant results to every user performing a search. I structured the rollout in four sequential phases, each with a clear delivery gate before the next phase activates. This meant we could isolate and fix any issue at the data layer before it became user-visible.
01
Data & Inventory
DS builds the BigQuery pipeline. Keyword inventory seeded for Dhaka, Chittagong, and Kathmandu. Internal review of keyword quality. No user-facing changes. Gate: inventory passes manual relevance review.
02
Ops Tooling & Pilot
S-D-1 and S-D-2 live in the Food Ops Dashboard. 5–10 pilot restaurants assigned keywords. QA validates the full 9-level ranking hierarchy using the canonical "Chicken" example in staging. Gate: QA sign-off on all ranking levels.
03
App Release
Badges go live in the app. Popular Searches dropdown activated. Analytics events instrumented, validated in staging, confirmed firing correctly in production. Gate: both analytics events validated end-to-end.
04
Commercial Sales
Sales team begins pitching packages with a standardised ROI deck: keyword search volumes, historical conversion rates, projected footfall lift. First contracts signed. Expiry tracking active in S-D-5.
The team
11 - Metrics
Three things I needed to be true simultaneously.
Success required hitting targets across three separate dimensions at the same time. Strong revenue with weak partner ROI means churn at first renewal. Strong partner ROI with degraded organic search means user trust erosion. I designed the metrics framework to catch failure in any dimension early - not just celebrate the commercial headline number.
Partner Outcome
Footfall & orders for paid restaurants
+50%
Target lift vs. each restaurant's pre-package baseline. The primary ROI signal for sales team renewal conversations.
Revenue
Non-commission revenue from package sales
New stream
First measurable non-commission earnings in Pathao Food history. No baseline to compare against - any revenue is progress.
Search Integrity - Guard Rail
Organic search CTR - must not decline
No regression
If organic positions lose click-through share post-launch, paid placements are crowding out relevant results. This fires an alert, not a celebration.
Discovery
Popular Searches tap rate
>15%
Target: more than 15% of search sessions should begin from a keyword tap in the dropdown, not just manual typing.
Retention
Package renewal rate at first expiry
>60%
If partners renew, they validated ROI themselves. A renewal rate below 60% means the ROI story isn't convincing - either the data or the product needs fixing.
System Health
Active keywords per city
>50 active
Minimum inventory depth for the Popular Searches dropdown to function well. Below this, the dropdown becomes too narrow to be useful and should be suppressed.
12 - Risks
What I was watching for at launch.
High
Paid results perceived as pay-to-win
Mitigated at the architecture level: DS-assigned keywords ensure paid restaurants only appear for relevant queries. The ★ and ◆ badges make commercial status transparent. P1 (exact name match) is inviolable - users searching a specific restaurant always find it first.
High
Poor keyword assignment degrades search quality
DS owns all assignments and reviews using the two-signal score (frequency + conversion rate). The ops Keyword Inventory View gives DS a clean view to spot and correct bad assignments before they reach production. No self-selection is permitted at any point in the workflow.
High
Ops can't manage the programme at scale
All four ops screens designed to be fully self-serve. The expiry-first sort in S-D-5 means proactive renewal is the natural daily workflow, not an afterthought. Immediate delete handles urgent cancellations without engineering involvement.
Medium
Partners churn at first contract renewal
The paid restaurant tap event was instrumented precisely to close this loop. DS can pull pre/post footfall data per restaurant from day one. The sales team was given a standard ROI reporting template before the first renewal cycle arrived.
Medium
Insufficient keywords in smaller cities
Popular Searches requires a minimum of 10 active keywords per city to display. S-D-3 shows current active counts. Phase 1 launched only in cities with sufficient search volume to seed meaningful inventories. Smaller cities were held until the inventory was ready.
Low
Ranking delay creates confusion
Package updates take effect next working day via batch. This was a deliberate design choice to avoid real-time race conditions, not a technical constraint. All stakeholders were briefed. Deletions are instant to handle the urgent case cleanly.
13 - Lessons
What I took away from building at the intersection of monetisation and trust.
01
The integrity constraint is the product, not a constraint on the product
The rule that restaurants can't self-select keywords was the single most important decision in this project. It was pushed back on early because it made the sales motion harder. But it's what makes the whole system trustworthy - and without trust, neither the user-side nor the partner-side value proposition holds. I learned to defend integrity constraints not as concessions to user trust but as the commercial foundation the product stands on. A paid search product that degrades into spam within six months earns less revenue, not more.
02
Fixed tiers beat auctions when ops simplicity is the bottleneck
There were early discussions about a real-time bidding model. I pushed back, not because auctions are bad, but because the ops and infrastructure complexity was wrong for where we were in 2024. A PM's job isn't to build the theoretically optimal system - it's to build the right system for the team's current capacity. The fixed-tier model shipped in one quarter. The auction model would have spent six months in architecture review and still not launched.
03
One concrete example beats three pages of spec rules
The "Chicken" worked example - a single query showing all 9 ranking levels with specific restaurant names - eliminated more ambiguity in ten lines than the rest of the ranking spec did in three pages. QA ran it in staging without clarification. Backend used it to validate their logic. Every team had the same mental picture. Specs are read once; a shared worked example gets remembered.
04
Sort order in an admin table is a product decision with real consequences
Defaulting S-D-5 to sort by upcoming expiry date was a small design call that had large operational impact. The ops team, opening the package management table each morning, immediately sees what needs attention today. If I'd sorted by restaurant name or creation date, renewal management would have required active filtering every day. Default states in tools compound across thousands of uses. Getting them right matters more than the feature itself.
05
This project was infrastructure first, revenue second
The keyword inventory, the 9-level ranking architecture, and the analytics events we built here were prerequisites for intent-aware search personalisation, keyword-driven collections, and the broader search renovation that followed at Pathao Food. The direct revenue was real, but the infrastructure leverage was the larger long-term win. If I were pitching this project again, I'd frame it as "search infrastructure that pays for itself while enabling the next two years of product work" - not just as a monetisation feature.