Explore

Solutioning

Current Setup

Pre Live Checks

⁠

Screenshot 2023-01-03 at 11.51.52 AM.png

⁠

Rectangle Box - System/DS based checks

Diamond Box - Manual checks

Tech Based

Validation Checks || System || TAT <1-2mins

What - System based checks on regex, pattern and custom rules.

Image format - Valid/Invalid Format

MRP > Meesho price

Mandatory fields - Filled or left Blank

Value not selected from dropdown for attributes

Variation level checks - Inventory, Mandatory fields.

Phone number, Email ID, comp websites checks on free text.

Where - Tech (Cis Validations)

Feedback and Action -

Shown up as validation failure on Supplier screen.

File is not processed for further validation. (Catalogs and Products are not formed)

Exact error is communicated to supplier at file level for bulk upload and catalog level for single upload.

Accuracy & Fallacy -

Near 100% accuracy for text validations and rules (New pattern and words can come in which are added reactively into the system)

Image validity checks - <100% accuracy, invalid image format can pass validations checks but can fail again in hygiene checks at later stages.

Nearly 8% of files uploaded through bulk upload gets failed on DoD basis and <1% files are failed on submissions done through single upload.

Hygiene Checks || System || TAT <1min

What - Supplier validity and product validity checks

Supplier is valid or not.

PSM and Product is valid or not (inventory related and product level flag, image links checks)

If a supplier/product status becomes valid again, these catalogs will be processed for further stages of going live.

Where - Tech (Cis & Go Live Validations)

Feedback and Action -

Currently there is no message/feedback that is being provided to supplier.

Failed files are stuck at QC progress stage on supplier panel, these catalogs will be shown to supplier in visibility V2.

Accuracy & Fallacy -

No leakages as per rules defined.

Go Live - Duplicity Checks || System || TAT 30 mins

What -

Checking whether a product is duplicate product coming from same supplier or is it a duplicate product coming from different supplier basis image similarity score.

Same supplier duplicates are deactivated by the go live service. The duplicacy checks are done basis image match score.

For some SSCATs we have put in place custom rules where attribute matching is considered along with image match score.

Where - Tech (Go Live Validations)

Feedback and Action -

Catalogs classified as same supplier duplicates by the Go Live are shown as duplicates under Blocked tab in inventory.

Accuracy & Fallacy -

Currently ~6% of the overall product inflow gets classified as same supplier duplicates.

Negligible false negative but the check does generate some false positive cases where a non-duplicate product gets classified as duplicate product, this is handled via uploader on admin which moves them from duplicates to limited visibility.

DS & Manual Ops

DS QC Jobs || System + Manual || TAT - 4hrs (2hrs Model Run, 2hrs Manual validation)

DS Brand QC

What - Sale of a tier 1 brand by a supplier without supporting documents (trademark certificate, brand authorization letter, purchase invoice etc.) to sell the brand is classified as a brand infringement.

How -

DS Model - The Brand Infringement Model convert text present on product image, product name and product description to textual tokenised form and then these inputs are taken as predictor variable for Brand Identifications. List of possible brand variations is present in

Brand List⁠

maintained by Ops team. Logo/Image identification is currently not part of this model.

Manual Ops -

DS model output is used by the Ops team to verify whether the image is of a branded product or not.

Post the branded products identification, Ops team cross check for Brand X Supplier authorisation and deactivate branded listing coming from non authorised sellers.

Feedback and Action - Ops team identify the infringements that are active in the system from the unauthorized suppliers and delist them through bulk delisting tool. Email communication to the suppliers requesting supporting brand documents.

Accuracy & Fallacy -

Of the total inflow flagged by Brand DS model predictions are generally correct on 44% of the cases. Rest 56% of the inflow is actually non-branded which is detected falsely as branded. This identification is done via agents.

19% of the branded inflow is missed by DS brand infringement model. (~3k products per day) - Methodology - We have defined a hold out group of 5% on total inflow where brand DS model predictions were blank, on this hold out group manual QC was done for all products to identify cases where DS model has missed predicting any brand or unauthorised classes. The 5% inflow is chosen randomly across relevant SSCAT so as to get a random but equal distribution of sscats resembling the actual inflow. Leakages on 5% inflow is extrapolated to total inflow to identify total misses per week by the DS model.

Major reasons for false negative (19% miss by DS brand Infringement model)

Changes related to SSCAT - DS brand infringement model have several SSCAT filter which filter out selected SSCATs for checking specific brands. For example brand “W” is an ethnic brand and ideallt should not be checked for electronics SSCATs. This is done to reduce false positive but sometimes it increases false negative due to following reasons-

Addition of new SSCAT.

SSCAT change during Ops QC/category team request.

Image based deactivations - Images which dont have branded keyword text on image or description or name cannot be classified as branded product by Brand DS model.

Other reasons -

Brand Name in the Image was not clear - Use of emoji/space

Brand Logo in the Image was not clear

Older (Pre DS model) Brand fakes products might still be visible on the platform, for all such brands we might need a one time clean up for respective brand/keywords. Recent case - Ray Ban

Brand Authorisation Process Gaps - Sellers submitting fake/false brand authorisation letter?

DS Unauthorised

What - Product classes that are banned from selling on E-commerce, categories like Guns, sexual (Images pertaining to profane image) , alcohol, car seat belt hacker, Tobacco, Indian flag & Pills fall under unauthorised classes.

How - DS profanity models is trained on images as well as take keywords as an input for predicting profanity/unauthorised classes.

Feedback and Action - Once the data is downloaded from the DS output, Agents start manual QC on that output. If the listing is found to be violating any

unauthorised guideline⁠

then the products are deactivated using bulk delisting tool.

Accuracy & Fallacy

Methodology - We have defined a hold out group of 5% on total inflow where brand DS model predictions were blank, on this hold out group manual QC was done for all products to identify cases where DS model has missed predicting any brand or unauthorised classes. The 5% inflow is chosen randomly across relevant SSCAT so as to get a random but equal distribution of sscats resembling the actual inflow. Leakages on 5% inflow is extrapolated to total inflow to identify total misses per week by the DS model.

Guns - Prediction Missed on daily inflow - 38% of the total Guns inflow or 20 products per day.

Alcohol - Prediction Missed on daily inflow - 0% of the total alcohol products or 0 products per day.

Sexual - Prediction Missed on daily inflow - 7% of the total Sexual products or 200 products per day.

Tobacco - Prediction Missed on daily inflow - 30% of the total Tobacco products or 28 products per day.

Sex Pills - Prediction Missed on daily inflow - 51% of the total Pills products or 1200 products per day. (we also have a separate Drug DS Model which handle some of the overlapping cases from here)

Drugs DS model - Prediction Missed on daily inflow - 7% of the total Drugs related products or 28 products per day.

Major reasons for false negative in DS Unauthorised model

Training Data - DS don't have enough images to train, all these models are binary classifiers which require clean and large dataset for better accuracy. Most of these classes have less than 1500 images and is not sufficient.

Changes related to SSCAT - DS Unauthorised infringement model have several SSCAT filter which filter out selected SSCATs for checking specific unauthorised classes.

Addition of new SSCAT.

SSCAT change during Ops QC/category team request.

Unauthorised classes are added onto the DS model and QC SOP as a reactive process. Case in point - ACID as a disposition of unauthorised class

Admin Panel QC || Manual || TAT - 4hrs (30mins Allocation, 3hrs Manual validation)

What -

Image Check: Check the image quality (if found an issue then deactivate the PID).

SOP⁠

⁠

Category Mapping: Check the Category (If found, the wrong category then correct it.)

SOP⁠

SOP1⁠

⁠

Product Name Check: When in a catalog the given product name does not relate to the actual product agents have to change it to a Generic name that matches the product

SOP⁠

⁠

Critical Checklists: Check if the Product is unauthorized or not, If yes then deactivate the PID.

S⁠

⁠

OP⁠

⁠

How - On Admin Panel by agents

Feedback and Action

Approved - If the catalog does not have any issue then mark the status as Approved.

Reject - If the catalog had an issue and we had corrected it then mark the status as Reject.

Deactivate - If the catalog consists of any unauthorized products then mark the status as deactivate.

Problem Highlight & Thinking Track [Reduce DoD Leakages]

Problem Statement - Reduce Brand/Illegal products on platform.

Definition of Brand Fakes/ilegal -

Product that resembles closely with branded goods (pictorially) or contains branded keyword in Product Name/Description/Image and is sold by a supplier who is not authorised to sell products of that particular brand or the product itself is unauthorised to be sold on E-commerce platform.

Problem of Brand Fakes/illegal Products

Why Brand Fakes show up on platform?

[Keyword Leakages] [P0 Problem]- Non branded/Brand Fakes/Illegal having problematic keyword in name/description/attribute are indexed by search, these leakages have very high affinity to search since search is indexed on keyword. Branded keyword search are also boosted in search ranking according to ranking logic and hence Brand Fakes with branded keyword becomes highly susceptible to get search views with high rank. (Also validated

here⁠

)

Why this happens: Pre Live Process Leakage: Due to SSCATs filters present in Brand Infringement model, certain Brand Fakes with Branded keyword stuffing get bypassed in DS Brand Infringement model.

Impact: 30% of leakages that happen for Brand Fakes contain Branded Keywords, these leakages have very high affinity to search since search is indexed on keyword. Branded keyword search are also boosted in search ranking according to ranking logic and hence Brand Fakes with branded keyword becomes highly susceptible to get search views with high rank.

Scope: Reducing keyword leakage will result in 30% of Brand Fake leakages and complete sanity of Brand search results. And non discovery of illegal listing when someone tries to search for one.

Why supplier use Brand Keyword? Do they use it intentionally or unintentionally?

[Intent Identification & Knowledge Gap] [P0 Problem] - Currently there is no mechanism to check whether a Supplier has the intent of committing fraud by genuinely uploading a Brand Fake or is mistakenly keyword stuffing in Non Branded inflow due to knowledge gap. Suppliers get delayed and generic feedback for breaching brand infringement guideline.

VOS -

23 out of 55 suppliers who wanted to sell branded items were not aware of brand approval guidelines and process on Meesho.

“Meesho blocks all catalogs repeatedly. Causing lots of loss to business” - Open rate for emails are very low amongst supplier where we communicate sellers about their listing deactivation. Such suppliers are not aware on why exactly their catalogs are getting deactivated and what are the next steps.

Resellers face problem in submitting Brand Authorisation - “Reseller ko authorization letters dene me problem hota kyu ki brand owner reseller ko authorization nahi deta hai jiske karn reseller brand product listing ko remove kar diya jata hai”

Impact: For cases where supplier are uploading catalogs with Brand Fakes, feedback starts coming in when supplier has already uploaded the product and products are deactivated, error communication is not precise and actionable are highly reactive in nature .

Scope: Direct and more customised feedback loop for cases where supplier unknowingly or knowingly make use of Brand Keyword variation in free text fields. Successful fraud detection will help deploy stricter validation for suppliers who have intent to upload Brand Fakes on platform.

Brand/Illegal Fakes (Identifiable only from image)

[Image based deactivations][Brand] [P1 Problem] - Currently DS models are not geared to handle Image only Brand Detection (Image based models are built for certain brands but not all). Product which don't have branded keyword text on image or description or name have a high chance from leaking in the Pre Live Process and Brand DS model.

Impact: Does not get indexed by search, mostly stay on the platform as passive leakage. Constitute to around 48% of the leakages from Brand DS model.

Scope: Removing Image based Brand Fakes will help make overall selection cleaner.

[Image based deactivations][Brand] [P1 Problem]

Thinking Track - Brand Fakes

Idea Proposal

Gating (Restricting) branded inflow at catalog upload stage with feedback loop set to supplier that can help them correct their catalogs or initiate process for brand authorisation approval.

For the initial version of the Brand Gating, we plan to use supplier level Regex checks on free text fields at catalog upload stage along with feedback & educational loop.

Why Regex Based?

Currently search indexes products based on keyword mentioned in Name, Description or Attribute. From the

analysis⁠

it is known that primary real estate for brand product discovery is through search and hence regex checks at catalog upload stage is prioritised over other input parameters like - Image (Other such p1,p2 parameters will be included in next iteration of Brand Gating). Also from compliance point of view - Authorities tend to search for potential Brand Fakes on platform which again ties the risk back to branded keyword present non authorised fake branded products. This is also benchmarked with other platforms like Amazon/Flipkart where sellers are not authorised to use Brand name which are they are not authorised to sell. More details on comp Benchmarking

here⁠

⁠

What kind of Feedback Loop?

[Education & Awareness] Supplier who do not have Brand Approval for using any Brand Keyword will receive warning prompt nudging them with correct course of action - [Brand Approval Process or Rectify Keyword] with a default option to submit catalogs anyways.

Supplier choosing to submit on warning message will be tracked for Brand Infringement cases

[Tracking Fraud] >> Warning Driven: If for certain supplier there are cases wherein products that were submitted (Over the warning) ends up breaching Brand Infringement guideline, the submission flow will change for such suppliers (refer to point b).

[Punishing Fraud] >> Validation Failure: For such identified suppliers, any products submitted with Keywords which the supplier does not have authorisation to sell, the supplier will start getting validation failure (i.e. will not be able to submit products unless he submits Brand Authorisation paper or corrects the brand keyword mentioned in respective field). Graphical Representation of Flow -

Here⁠

⁠

Why at catalog upload stage?

[Actionability] - Knowing that supplier has used restricted keyword will help him rectify the listing or submit brand approval at the time of upload when intent is high.

[Efficacy] - Ensuring all branded keywords are blocked at catalog upload stage, all keyword related brand infringement will be marked for QC in downstream process ensuring that there are no keyword based leakages in the live inflow. Making the complete process more robust. (Current Leakage due to keyword misses is around 30%, i.e. Brand Fakes that are leaked on platform, 30% of them have Branded Keyword stuffing in them).

[Feedback] - Currently the messaging happens post QC process where deactivations has already happened for the problematic products. Gaps in such communication

[Knowledge Gap] - Supplier awareness gap on usage of Branded keyword, currently suppliers are not aware on kind of keywords they are allowed to use during catalog upload.

[Process Gap] - Suppliers who already have Brand Authorisation letter do not have a very clear process of submitting these documents while uploading branded products.

[Fraud Intent] - We want to make sure suppliers with repeated offence go through more stringent screening on the platform before their catalogs are uploaded on to the system.

Flow Highlight

⁠

⁠

Derived from

here⁠

⁠

Bridging Pre Live Process gaps

Brand/Keyword Gating

Existing flow for Brand Detection and Deactivations of unauthorized brand activations.

⁠

⁠

We are trying to cover following gaps as part of Brand/Keyword Gating Process during Catalog Upload -

Reduce TAT for Branded/Restricted inflow detection through DS model on description based keyword checks.

Reduce leakages that are caught at Keyword Process due to SSCAT change or Inclusion/Exclusion filter.

Automate the process of Brand Approval, digitize and create digital repository for Brand Approval records at supplier level.

Identify Fraud Supplier (who have intent of committing fraud) from Supplier who does have intent of committing fraud.

Approach 1 - Recommended (Brand Gating V1)

1. Introduce Regex checks for complete Suraksha lists without SSCAT filter.

2. The validation check will happen at supplier level where only authorized sellers for each keyword will be allowed to input the brand name/or its variation in the product name and description.

3. Failed validation will prompt Supplier to

Accept listing with the warning - Listing/Account Deactivation And

Submit authorisation document via self serve which can be further taken for manual verification, verification logs to be maintained in the system.

4. Case when supplier chooses to submit the catalog post the warning and gets a brand infringement deactivation later on that product - This will count as a strike, post X (X could be 3,5 etc) strikes instead of warning his listing will start going into validation failure (instead of error message) whenever there is any usage of keyword variation coming from Suraksha List.

⁠

Screenshot 2023-01-23 at 10.44.02 PM.png

⁠

Pros:

Regex checks irrespective of the SSCAT, which means 100% inflow is filtered for all critical tier-1 brand keywords and its variation.

Rectifications on keywords can be done during catalog upload stage (Error Communication during submit step), reducing the potential unauthorized branded inflow that goes into the system.

Suppliers can do brand authorisation via self-serve manner at the time of catalog upload.

Complete coverage of Suraksha list.

No/little impact on genuine LbyS

Differential handling based upon criticality of brand and intent of supplier.

⁠

Screenshot 2023-02-01 at 10.09.10 AM.png

⁠

Alternative Approach

1. Introduce Regex checks for all Tier-1 Brand keywords (& variations) along with a critical restricted keyword list (SSCAT agnostic)

2. The validation will happen at supplier level where only authorized sellers for each keyword will be allowed to input the brand name/or its variation in the product name and description.

3. Failed validation will prompt Supplier to submit authorisation document via self serve which can be further taken for manual verification, verification logs to be maintained in the system.

⁠

⁠

Pros:

Regex checks irrespective of the SSCAT, which means 100% inflow is filtered for all critical tier-1 brand keywords and its variation.

Rectifications on keywords can be done during catalog upload stage (Error Communication during submit step), reducing the potential unauthorized branded inflow that goes into the system.

Suppliers can do brand authorisation via self-serve manner at the time of catalog upload.

Cons

Since the regex checks will be created at catalog upload stage, this might increases the false positive cases of validation failure (For example “Noise” might throw up error on submission for unauthorized sellers using “Noise” as a keyword in their name or description, which actually is a very generic keyword).

Possible workarounds on Cons -

Add set of negative keywords against each brand to reduce false positives.

Restrict regex checks to non generic branded keywords (handle common keywords through Brand DS model which are already tuned to handle common word cases)

Solutioning Details

Overall Catalog Upload Flow

⁠

⁠

Overall Handling of different cases -

Differential handling based upon criticality of brand and intent of supplier.

Overall Catalog Upload Flow

⁠

@Nihal Singh

⁠

this is the flow we follow to decide the gating mechanism in V1

Tiering of Suppliers

In last 120 days around 2 lakh sellers have uploaded catalogs

26k have tried to upload branded catalogs

Rest 1.74 lakhs have uploaded non branded catalogs

To selectively educated, restrict and block these sellers from using brand/restricted category keyword we will be dividing them into different groups.

We have defined cohorts of supplier P0, P1, P2 & P3 based upon the nature and pattern of brand fake deactivation, this grouping can help us pre meditate suppliers who have the intent of committing fraud.

P1: Initial stage of fraud detection, these suppliers are suspected of fraudulent activity and carry potential Brand Fake risk associated with their live listing or new catalog upload. 5% of P1 sellers are converted into P0 sellers on WoW basis.

Criteria used to classify these seller:

(frequency<=5 ) and ((deactivation_percentage>=0.1 and frequency<=2 and deactivated_products>5) or (deactivation_percentage>=0.05 and deactivation_percentage<0.3 and frequency>=2)) and (deactivated_products<4000)

P1 sellers (~6-7k) contribute to around 11% of Brand Fake deactivation on platform,

P0: Critical stage of fraud detection, Live and newly uploaded catalogs of these suppliers are expected to be Brand Fake in nature. 80-85% of incremental sellers coming in this cohort graduate from P1 cohort, remaining % enter directly into this cohort.

P0 (~3k) seller contributes to around 84% of Brand Fake deactivation on platform

Criteria used to classify these seller:

(frequency>5 ) or (deactivation_perc > 0.3 and frequency>2) or (deactivated_products>=4000)

How P1 sellers graduate to become P0 sellers

⁠

Screenshot 2023-02-09 at 12.13.52 AM.png

⁠

P2: Non P0/P1 case of seller with atleast one illegal/brand deactivation in last 120 days. P3: Seller with no record of brand/illegal deactivation in last 120 days.

Keyword Tiering

Tiering of Keywords based upon their criticality

⁠

https://docs.google.com/spreadsheets/d/1mKgfaXRxG7lEIZj-lIg533XiNpBAOJOtPE_cJh9s81w/edit#gid=0⁠

⁠

Detailing

Catalog Upload (Backend Flow detailing)

Keyword Regex checks on catalog upload for both single and bulk upload

(Keyword Variation Table) - A master list of Keywords, their variation and relevant tags saved and updated in mercury table by QC ops. This will act as a source for keyword based regex.

⁠

(Supplier Authorisation Map) - A master list of all Brand_Name and sellers who are authorized to sell that brand will be saved in another mercury table -

Common key between the Keyword variation Table will be the brand_name table

A mapping of sellers P0,P1, P2 & P3 will be stored in model table which will give flag at seller level (P0,P1)

Model table name - gold.repeated_offenders_weekly. This table will be updated daily to flag all (P0 &P1) sellers

Differential Handling of keyword & supplier group

Regex checks (nature)

For any free text field or Brand related field (fields which have Brand in their name) in taxonomy or psm level apply keyword based regex based on keyword variation present in Keyword Variation Table.

mercury.gdrive__ds_brand_list⁠

⁠

Regex should be the exact matches of the keyword present in the variation map (including lowercase & uppercase variation). This should not be a partial match since we have some very small brand keywords like “Mi” as brand name which can get flagged at later stages where it was only used inside of some broader word/sentences (for example - “Good looking mittal saree” keyword “mi” should not be partially matched with the sentence here.

Regex check should happen for the key - i.e. Brand_Name and as well as they variation of it stored in the variation column of Keyword Variation Table.

Validation Failure Cases:

Keyword tags flagged for validation failure by regex checks during submission (for bulk upload - Template upload) then for that keyword variation, check its corresponding brand_name in Keyword Variation Table. (For example if l-a-k-m-e has a regex check with supplier provided input, look for its proper brand name in brand_name column - i.e. Lakme).

Then check for supplier entry in Supplier Authorisation Map. If a particular supplier has an entry with brand_name (common key between Keyword Variation Table & Supplier Authorisation Map) then allow normal catalog submission - No change in submission flow

If for any keyword regex match the supplier entry is not present in Supplier Authorisation Map against the corresponding brand_name for the keyword variation, do a validation failure of the file.

Single Upload - Throw error highlighting problematic fields with mention of problematic keywords used in that field. (Async on Submission)

Bulk Upload - throw row level error writing error with problematic keywords in the error and attribute names with which error was associated with. (Async on Submission)

Details on Single and Bulk flow here -

Solutioning⁠

⁠

Warning Nudge Cases:

If any keyword is for warning flagged by regex checks during submission (for bulk upload - Template upload) then for that keyword variation, check its corresponding brand_name in Keyword Variation Table. (For example if l-a-k-m-e has a regex check with supplier provided input, look for its proper brand name in brand_name column - i.e. Lakme).

If for any keyword regex match the supplier entry is not present in Supplier Authorisation Map against the corresponding brand_name for the keyword variation, throw a warning nudge at upload/submission time.

Details on flow here -

Solutioning⁠

⁠

On all cases where submission is happening fail hygiene check (make product value=0 by default, reactivation or flag change will be done by QC team on uploading eligible catalogs, Go live will pick these catalogs for activation once their hygiene checks are changed)

Overall Catalog Upload Flow

⁠

Priority order of Warning Nudge, Validation Failure & Submission behaviour - Design

Approach 1 - Validate Warning cases and Validation fail cases at one go (Async)

Single

If file has both warning & validation fail case - show as QC error with summary error and then option of editing the catalog with field level error (existing behaviour).

On re-submission if validation & warning cases are flagged again follow 1

On re-submission if warning cases persist but validation error gets corrected, create a new state - “Warning State” in catalog upload section and let supplier correct the listing by editing or proceed of final submission. - (new behaviour)

On re-submission if warning cases gets resolved but validation persist follow 1

If the file only has only warning cases - create a new state - “Warning State” in catalog upload section and let supplier correct the listing by editing or proceed for final submission (2nd Submission). - (new behaviour)

On Correction and resubmission if validation error comes follow 1

On Correction if warning & validation error arises follow 1

On correct if warning error persist follow 2 again.

Bulk

If file has both warning & validation fail case - show warning state with an option to download file or move ahead for submitting it anyways

On downloading warning file both warning error and validation error should get clubbed at row level.

On re-submission

If File has no Validation or Warning error -it becomes QC pass.

If File has only validation error - change state to QC error

If File only has warning error - Follow 2

If File only has both - Follow 1

If file only has warning cases then- change state to warning state and option to download file or move ahead for submitting it anyways

On downloading warning file both warning error are clubbed at row level.

On correction

If there is warning & validation error - Follow 1

if there is only warning case - Follow 2

if there is only QC error - change state to QC error

(In both cases non problematic products are submitted automatically on 1st submission)

Approach 2 (Preferred) - Validate Warning cases (Happens in Sync for Single & Mweb) and Validation fail cases (Async)

Single

Validation Failed Cases

Prompt with summary of errors highlighted

Redirection

To go back to upload form correct errors (error should be at field level)

Option to report a error (if its not relevant) - TBD

Keep catalog in draft and proceed to support section for Brand Auth request

Warning Cases

Trigger warning prompt screen on submission with summary of errors highlighted

Redirections

To go back to upload form correct errors (error should be at field level)

Option to report a error (if its not relevant) - TBD

Submit catalog and proceed to support section for Brand Auth request

Submit Catalog Anyways

Bulk

If file has both warning & validation fail case - show warning state with an option to download or upload file or move ahead for submitting it anyways

On downloading warning file both warning error and validation error should get clubbed at row level.

On submission/re-submission

If File has no Validation or Warning error -it becomes QC pass.

If File has only validation error - change state to QC error

If File only has warning error - Take final submission

If File only has both again - Follow normal QC error route (existing Behaviour)

If file only has warning cases then- change state to warning state and option to download file or move ahead for submitting it anyways (final submission)

On downloading warning file both warning error are clubbed at row level.

On correction

If there is warning & validation error - Change to QC error

if there is only warning case - Take final submission

if there is only QC error - change state to QC error

(In both cases non problematic products are submitted automatically on 1st submission)

Deactivation First Activation later - Expectation setup

Flag to consider - PSM/Product

Objective - To fail warning products in go live chain

Warning flagged cases might take more time than usual to go live since they will be selectively reactivated only after manual QC. We need to make sure expectation is set to sellers about all such catalogs at the submission stage.

Should communicate about possibility on delayed and selective activation basis QC.

We should log all these cases in visibility logs and map correct reason for these catalogs

Something on the line which expresses that catalogs can activated if they pass QC otherwise they will remain deactivated due to failure with compliance.

Messaging & Nudges <V1>

Warning Nudge:

Should communicate about consequence of using restricted brand in keywords - Listing getting deactivated, temporary seller account deactivation.

Should be actionable in nature

Should highlight summary of problematic keywords in the error prompt.

At catalog upload form level - Should highlight all fields where regex pattern was caught and problematic keyword should be included in the error description near that field.

Should communicate about possibility on delayed activation on warning flagged catalogs - More

here⁠

⁠

Regex checks <V1>

Regex checks pattern

“puma store” - should be flagged kajsdpuma storeslfddkf

skjdsdb Huda Beauty skjdbs sjdbsjdb sjd, sjhdbshdb skdjn ......huda beauty...... smdnsd

pumastre - should not be flagged sippuma - should not be flagged $#puma - should be flagged ..puma - should be flagged puma..$$ should be flagged

Maybe we will have to use regex here for implementation, For the free text where we need matching - left side could be non letter (except space) or beginning of the string itself. And right side could be end of string or some non letter. For example in case of MTP Pills Regex would then be (?i)(?<=^|[^a-z])MTP Pills(?=$|[^a-z])

More details here -

https://www.rexegg.com/regex-boundaries.html#real-word-boundary⁠

and broader details here -

https://www.rexegg.com/regex-boundaries.html#:~:text=(direct%20link)-,Word%20Boundary%3A%20%5Cb,string%20or%20a%20space%20character).⁠

Missed cases of reactivation <V3>

Current manual error in deactivating eligible cases is <5%

This manual error in reactivation can lead to eligible catalogs not getting reactivated (How to handle such cases?)

TAT for reactivation in Go Live

Catalog Edit <Can be scoped out since we are already blocking catalog edit for P0 & P1 seller)

Regex checks to be retained

We should throw validation failure on submitting changes

⁠

⁠

Catalog Edit QC Bandwidth to be leveraged for checking keyword stuffing on cases where warning nudge was flagged.

Case: Brand Authorisation comes, what happens to Old deactivations?

Current SOP -

https://sites.google.com/meesho.com/cataloging-qc-kb/cataloging-qc/reactivation-process⁠

⁠

Simplification

We will have to remove brand attribute from simplification flow

Data Requirement (V1 BE)

Table

Product ID

Field

Warning Keyword

Validation Keyword

Timestamp

File Ref ID

12923

Name

Nike,Puma,Ray Ban

Lakme,Gucci

3434

Descrption

Armani

12923

Brand Attribute

Adidias

There are no rows in this table

⁠

to provide any additional columns

Data Points - Warning Nudge/Validation Failure

WIP

Why we need tiring of keywords to consider cases where generic names are used in brand or restricted classes - There are lot of generic keyword in consolidated brand & restricted keyword list which might not lead to deactivation and hence severity of their submission will be taken into account.

Sample generic keywords and products uploaded with keywords in description on a given day

~3.5% of false positive case on overall inflow (Exc cases & cover, 10k Products flagged, actual deactivations ~3k per day)

(DoD flagged listing ~

Sample Generic Keyword

Product Count at Supplier Level

Apple

366

boAt

253

Comfort

158

Cleaner

forever

acid

Eyeconic

Dollar

Unwanted

EVERYDAY

Alcohol

bullet

There are no rows in this table

⁠

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

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.