Skip to content
Moving view dipstick process on admin panel for North star tracking for increased efficiency (Saving 2.5 hrs ops per day)Creating the ability to do RCAs on view share troughs or peaks from centralised instrumentation
No visibility on prior DS flagging to the teamInstrumentation of product’s brand or illegal class happening on sheets which has leakages in terms of concrete feedback mechanism to DSNo or limited visibility of products mapped under brand as well as illegal class from DSDowntime in ops team prepping daily data and manually assigning to agents, finally followed by manual bulk deactivations towards end of the day
Create a admin tab which showcases all products part of daily dipstick model run with following parameters - All images of the productPossible to zoom in images Creation date for the productSupplier ID and seller nameProduct ID, name and comment - Check if catalog detail / sharetext are neededbrand / brands / trend / originals / brand_compatibility fields from taxonomy DB - Showcase this as brand added by sellerPrior brand flagging by DS - To be mapped from gold.brand_infringementPrior illegal class flagging by DS - To be mapped from silver.profanity_filteris_indian_flag = 'Yes' or is_sexual_product = 'Yes' or is_alcohol_product = 'Yes' or is_tobacco_product = 'Yes' or is_gun = 'Yes' or is_seatbelt_clip = 'Yes'
or is_pill = 'Yes' or is_oil = 'Yes'The field will concatenate the cases where DS flags it to be true Eg - {Indian Flag, Oils}, In case is_indian_flag ‘ Yes’ and is_oil =’Yes’Flag if seller is authorised to sell the brand - Need to map whether seller is authorised to sell the brand or not from - mercury.gdrive__surakshra_list_masterThis will be checked as an on-demand API based on the brand flagged by the agentFlag for multiple seller mapping - Binary flag which is set to 1 in case product is mapped to multiple sellersHere agents will delist PSM for brand leakages, and delist catalog + product for illegal or blacklist brand leakagesWe’ll record 2 mandatory inputs from agents per PID - Per product QCed, agents will have the option to do the following - Action - Mark as false positiveDeactivate catalog / product - This will delist product as well as catalog and store the deactivation disposition as ‘Brand deactivation Based on Views’Deactivate PSM - This will mark PSM.valid as 0 and store the deactivation disposition as ‘Brand deactivation Based on Views’All above deactivations need to be logged in taxonomy-deactivation-reasonsRecording identified brand / illegal class - MandatoryThis will be a dropdown of all brands part of Suraksha list here - mercury.gdrive__ds_brand_listThis will also have an union of illegal classes - To be shared by and Alternative keywords detected - Free text input - To be logged separately per brand name (Non mandatory input)Allocation of PIDs per agent - Post daily query output, allocated files per agent will be visible basis a parallel file uploader where ops team will tag individual PIDs per day to agent’s email IDPost file upload, allocate PIDs per agent will start showing in their individual windowsThis is similar to the implementation of file allocation for manual QCMaster PID search -While daily data will be basis PIDs part of presto model and allocations per agent, This console would also have a on-demand API to fetch all details listed in point 1 for any PID searched from hereThis will assist in ad-hoc group tagging as well as to handle certain escalationsDeactivation CRON setup - Agents will only have the option to record the brand or illegal class tagged per PID in adminThe data from PID level tagging will be written into noSQL / presto DBIf a PID is tagged from one duplicate group, then all mapping products from the mapped group would also need to be deactivatedAll products tagged to the group would need to be deactivated and be logged in the instrumentation table above. Deactivation methodology would remain the same throughout as stated below.A two hourly CRON would read from this and deactivate both catalog and product with source - Views dipstick CRON except for below case -The CRON would only deactivate PSM.valid in case the product is mapped to more than 1 supplier and the supplier maps to authorised brand against the brand name tagged by agentsIn these cases catalog and product won’t be invalidatedThis won’t work for any illegal class taggingQuery for regex map / match from brand name to authorised seller IDs placed below
The details of identified brand or illegal class would need to be persisted in a Presto table for DS feedback loop
Admin views dipstick
Objective -
Current process overview -
On a daily basis, We aggregate all top PIDs trending across major branded search queries + Indexing on top of other feeds (PDP reco / FY etc).
Cataloging ops team QCs these listings on a daily basis and deactivates the leakages from the platform.
Details of model referred by ops for daily dipstick QC to be shared here -
Brand Views -
select
a.catalog_id, a.brand_name, a.views, a.supplier_id, a.authorized,brand_aut_non_auth_rank
from (select catalog_id, brand_name, views, supplier_id, authorized,brand_aut_non_auth_rank from gold.brand_searches_top_catalogs_daily
where authorized = 0 and brand_aut_non_auth_rank <= 100 and created_date = current_date - interval '1' day
Unauthorized Views
select
catalog_id
,created_date
,min(brand_rank) as brand_rank
,min_by(brand_name,brand_rank) as brand_name
from gold.keyword_searches_top_catalogs_daily
where created_date >= date'2023-02-20'
group by 1,2
having min(brand_rank) <= 100
This whole process is driven off panel in google sheets which makes the identification prone to following misses -
Proposed changes -
@Kishor
@Srinivasa Rao Jami
Instrumentation -
FE design mock -
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.