Ad Accounts पर Restriction क्यों लगती है — और इससे कैसे बचें

ज़्यादातर ad account restrictions बेतरतीब नहीं होतीं। ये परतदार automated review का नतीजा हैं, जो आपकी copy, creative, landing page, बिलिंग डिटेल्स और लॉगिन पैटर्न को एक ही risk profile की तरह पढ़ता है। कौन-सा signal सिस्टम में फँसा, यह समझना ही दो दिन की appeal और हमेशा के लिए गँवाई गई asset के बीच का फ़र्क़ है।

"Ad Account Restricted" का असल मतलब: enforcement की चार परतें

Advertisers अक्सर हर enforcement को "ban" कह देते हैं, लेकिन platforms अलग-अलग स्तरों पर कार्रवाई करते हैं, और स्तर ही तय करता है कि असर कितना फैलेगा और appeal का रास्ता क्या होगा। किसी creative का rejected होना रोज़मर्रा की सफ़ाई है। लेकिन restricted business portfolio या Business Center उससे जुड़े हर child account, pixel और catalog को जमा सकता है।

कुछ भी appeal करने से पहले परत पहचानें। ग़लत स्तर पर appeal करना गिनती के रिव्यू मौक़ों में से एक बर्बाद कर देता है।

• Ad या ad group स्तर: कोई एक creative disapprove होता है; बाक़ी अकाउंट delivery करता रहता है।
• Ad account स्तर: delivery रुक जाती है, लेकिन assets, audiences और conversion history आमतौर पर बची रहती है।
• Business portfolio / Business Center स्तर: नीचे मौजूद हर ad account, page और pixel तक असर फैलता है।
• Payment profile स्तर: बिलिंग या verification होल्ड, जो तकनीकी रूप से policy कार्रवाई से अलग है।
• Identity स्तर: कोई जुड़ा हुआ page, Spark Ads में इस्तेमाल हुआ TikTok handle, या किसी admin की personal profile फ़्लैग हो जाती है।

Copy, creative और landing page में policy उल्लंघन

यह आज भी सबसे बड़ी अकेली वजह है। Automated classifiers ad text, स्क्रीन पर लिखा टेक्स्ट, ऑडियो, thumbnails और destination URL को एक साथ देखते हैं — इसलिए एक compliant ad भी अगर non-compliant landing page पर भेजता है तो फ़ेल होता है। Google की destination requirements और Meta की landing page जाँच, दोनों वही क्रॉल करती हैं जहाँ यूज़र असल में पहुँचता है, redirect व्यवहार समेत।

व्यक्तिगत विशेषताओं वाली भाषा (यूज़र की मानी हुई सेहत, क़र्ज़ या शरीर को संबोधित करना), गारंटीड नतीजों का इशारा, before/after तस्वीरें, और countdown वाला दबाव — तीनों बड़े platforms पर बार-बार यही गड़बड़ियाँ पकड़ी जाती हैं।

• प्रोडक्ट के बारे में तीसरे पुरुष में लिखें, यूज़र की हालत या माली हालत के बारे में दूसरे पुरुष में नहीं।
• नतीजों की निरपेक्ष भाषा — "guaranteed", "cure", "fixed income", "risk-free" — copy और स्क्रीन टेक्स्ट दोनों से हटाएँ।
• Landing page का headline ad के ऑफ़र से मिलाएँ; बेमेल होना bait पैटर्न जैसा पढ़ा जाता है।
• संपर्क विवरण, रिफ़ंड, शिपिंग और प्राइवेसी पेज लाइव रखें और एक क्लिक में पहुँच में रखें।
• Redirect chains और geo- या user-agent आधारित कंटेंट बदलाव से बचें — दोनों circumvention में गिने जाते हैं, जो सख़्त enforcement श्रेणी है और जिसमें appeal के आसार कमज़ोर होते हैं।

अचानक खर्च की छलाँग, पेमेंट बेमेल और अकाउंट का भरोसा इतिहास

नए अकाउंट का भरोसा कम होता है। एक ताज़ा अकाउंट जो छोटे daily बजट से एक ही दिन में कई हज़ार पर पहुँच जाए, hacked या किराए पर लिए गए asset जैसा दिखता है, और risk सिस्टम उस आकार पर कार्रवाई कर देते हैं — performance सिस्टम को देखने का मौक़ा मिलने से पहले ही।

स्केलिंग का अनुशासन delivery की भी रक्षा करता है। हर ad set को learning phase से बाहर आने के लिए हफ़्ते में लगभग 50 conversions चाहिए, और बड़े बजट बदलाव उसे रीसेट कर देते हैं। Advantage+ या CBO में पुनर्आवंटन campaign स्तर पर होता है, इसलिए हद से बड़े क़दम एक ad set नहीं, पूरे campaign को अस्थिर करते हैं।

बिलिंग का बेमेल दूसरा ट्रिगर है: cardholder का नाम, बिलिंग देश और बिज़नेस entity, अकाउंट की currency, time zone और verification दस्तावेज़ों से मेल खाने चाहिए।

• बजट लगभग 20–30% के क़दमों में बढ़ाएँ और अगले क़दम से पहले 2–3 दिन delivery को दोबारा जमने दें।
• एक मुख्य पेमेंट मेथड और एक बैकअप रखें; बार-बार बदलना fraud signal है।
• फ़ेल हुए चार्ज तुरंत निपटाएँ — बक़ाया बैलेंस अपने आप होल्ड लगा देता है।
• जिन अकाउंट्स को स्केल करना है उन पर virtual या prepaid कार्ड से बचें।
• Business verification खर्च बढ़ने से पहले पूरा करें, restriction लगने के बाद नहीं।

साझा IPs, डिवाइस और Business Manager की सफ़ाई

Platforms browser fingerprints, IP रेंज, पेमेंट इंस्ट्रूमेंट और साझा admins के ज़रिए अकाउंट जोड़ते हैं। अगर एक admin कई restricted portfolios पर बैठा है, तो वह जुड़ाव स्वस्थ अकाउंट्स को भी नीचे खींच सकता है। इसी वजह से क्लाइंट्स के बीच लॉगिन साझा करने वाली agencies को झुंड में restrictions मिलती हैं।

साझा credentials के बजाय ढाँचागत एक्सेस इस्तेमाल करें: partner access और asset sharing वही ऑपरेशनल नियंत्रण देते हैं, बिना identity signals को आपस में मिलाए।

• हर browser profile पर एक admin पहचान, स्थिर लोकेशन के साथ — सेशन के बीच VPN बदलने से बचें।
• एक्सेस partner या asset sharing से दें, कभी लॉगिन credentials सौंपकर नहीं।
• नए यूज़र परखें: enforcement इतिहास वाले किसी व्यक्ति को जोड़ना जोखिम भी साथ लाता है।
• Portfolio के हर admin पर two-factor authentication अनिवार्य करें।
• अलग ब्रांड अलग portfolios में रखें ताकि एक restriction पूरे ढाँचे में न फैले।

बचाव चेकलिस्ट और restriction लगने पर क्या करें

बचाव ज़्यादातर लॉन्च-पूर्व अनुशासन है। हर asset को platform के मौजूदा policy पेज से मिलाकर देखें, पहले rejected हो चुके वाक्यांशों की अंदरूनी ब्लैकलिस्ट रखें, और quality signals पर नज़र रखें — बढ़ती frequency और negative feedback अकाउंट quality स्कोर गिराते हैं और delivery limits तक बढ़ सकते हैं।

अगर restriction लग जाए, तो पहले वजह ठीक करें, फिर सबूत के साथ एक बार appeal करें। एक ही मुद्दे पर बार-बार appeals अक्सर अपने आप बंद कर दी जाती हैं, और appeal की खिड़की छोटी होती है। साथ-साथ निरंतरता की योजना रखें: एक अलग verified portfolio, या WoAgency जैसे agency partner से रिप्लेसमेंट अकाउंट, रिव्यू लंबित रहते हुए कैंपेन चलाए रखता है।

उसी डिवाइस, domain और कार्ड पर दोबारा ढाँचा कभी न खड़ा करें जिन पर अभी फ़्लैग लगा है — यह जुड़ाव आमतौर पर पकड़ा जाता है।

• लॉन्च से पहले: copy, creative का टेक्स्ट, ऑडियो और landing page को एक इकाई मानकर policy-चेक करें।
• 7-दिन की frequency सीमित रखें और negative feedback जमा होने से पहले creatives बदलें।
• Conversions API या समकक्ष से server-side events भेजें, consent के साथ और सही नामों वाले standard events के रूप में।
• Restriction पर: appeal से पहले अकाउंट की स्थिति, delivery डेटा और landing page के स्क्रीनशॉट लें।
• बिज़नेस रजिस्ट्रेशन, domain मालिकाना हक़ का सबूत और सुधार का संक्षिप्त नोट लगाकर एक स्पष्ट appeal दाख़िल करें।

सवाल-जवाब

और गाइड