مواد پر جائیں
HA_

← تمام تحریریں

· 4 منٹ کا مطالعہ

کسٹمر کے اکاؤنٹ میں کبھی خاموشی سے کارروائی نہ کریں

ClickFortify کسٹمر کے اشتہاری اکاؤنٹ میں پس منظر میں کبھی کچھ کیوں نہیں بناتا، اور ایسا کرنے سے پہلے جائزے کے مرحلے میں کیا دکھانا ضروری ہے۔

productarchitectureadtech

مشینی ترجمہ۔ اصل تحریر پڑھیں

ClickFortify دوسروں کے سسٹمز کے اندر کام کرتا ہے۔ خراب ٹریفک کو خارج کرنے کے لیے اسے کسٹمر کے Google Ads یا Meta اکاؤنٹ سے جڑنا اور وہاں تبدیلیاں کرنی پڑتی ہیں۔ یہ رسائی پروڈکٹ کی بنیاد ہے، اور یہی وہ حصہ بھی ہے جس کے بارے میں میں سب سے زیادہ محتاط رہتا ہوں۔ اسی احتیاط سے ایک اصول نکلا، اور اب یہ ہر ملتے جلتے معاملے کی سمت طے کرتا ہے: ہم کسٹمر کے اکاؤنٹ میں کبھی خاموشی سے کارروائی نہیں کرتے۔

یہ اصول کہاں سے آیا

Meta کنیکٹ پر کام کے دوران یہ تجویز آئی کہ اگر کسٹمر کے پاس Meta Pixel نہ ہو تو اسے خودکار طور پر بنا دیا جائے۔ بظاہر یہ مددگار لگتا تھا۔ کسٹمر کو pixel چاہیے، ہم اسے بنا سکتے ہیں، تو پوچھنا کیوں؟

میں نے اسے مسترد کر دیا۔ اس لیے نہیں کہ pixel خطرناک ہے، بلکہ اس مفروضے کی وجہ سے جس پر یہ شارٹ کٹ قائم ہے: کہ ہم کسٹمر سے بہتر جانتے ہیں کہ ان کے اکاؤنٹ میں کیا موجود ہونا چاہیے، اس کا نام کیا ہونا چاہیے، اور اسے کہاں ہونا چاہیے۔ ہم نہیں جانتے۔ یہ ان کا اکاؤنٹ ہے۔

اس کے بجائے ہم کیا کرتے ہیں

کوئی بھی فلو جو کسٹمر کے بیرونی اکاؤنٹ میں کچھ بنائے، پہلے جائزے کا ایک مرحلہ دکھاتا ہے۔ اس مرحلے کے چار حصے ہیں:

  • قابلِ ترمیم نام۔ ہم ایک نام تجویز کرتے ہیں، اور کسٹمر اسے بدل سکتا ہے۔
  • یہ کہاں بنایا جائے گا۔ وہ اکاؤنٹ یا بزنس جس کے تحت یہ ہوگا، واضح الفاظ میں۔
  • ہم اس کے ساتھ کیا کریں گے۔ ایک دیانت دارانہ جملہ کہ ہمیں اس کی ضرورت کیوں ہے۔
  • ایک Create بٹن جسے کسٹمر خود دبائے۔ پس منظر میں کچھ نہیں ہوتا۔

ڈیفالٹس میں کوئی حرج نہیں۔ اچھا ڈیفالٹ کسٹمر کا وقت بچاتا ہے، اور زیادہ تر لوگ اسے قبول کر لیں گے۔ خاموشی سے عمل درآمد درست نہیں۔ دونوں میں محنت کا فرق چھوٹا ہے مگر مطلب کا فرق بڑا: ڈیفالٹ کے ساتھ فیصلہ کسٹمر کرتا ہے؛ جائزے کے مرحلے کے بغیر ہم ان کی جگہ فیصلہ کر لیتے ہیں۔

یہ اصول صرف pixels تک محدود نہیں۔ یہ ہر اس چیز پر لاگو ہوتا ہے جو ہم کسٹمر کے اکاؤنٹ میں بنا سکتے ہیں، چاہے وہ کوئی ٹیگ ہو، کوئی آڈینس ہو یا پلیٹ فارم پر کوئی اور entity۔

// Illustrative: a change we propose, but never apply on our own
type ProposedAction = {
  kind: 'create';
  resourceType: string;  // what will be created
  name: string;          // suggested by us, editable by the customer
  parentId: string;      // the account or business it will live under
  purpose: string;       // what we will do with it, in plain words
  confirmedBy?: string;  // empty until the customer presses Create
};

سب سے مفید خصوصیت آخری فیلڈ ہے۔ جب تک کوئی انسان کارروائی کی تصدیق نہ کرے، یہ صرف ایک تجویز ہے۔

یہ کیوں اہم ہے

نام اور جگہ کا اختیار کسٹمر کے پاس رہتا ہے۔ اشتہاری اکاؤنٹ شاذ و نادر ہی کسی ایک شخص یا ایک ٹول کے استعمال میں ہوتا ہے۔ ایسا resource جس کا نام کسی نے نہ چنا ہو، اور جو ایسے بزنس کے تحت ہو جسے کسی نے منتخب نہ کیا ہو، بہترین صورت میں بے ترتیبی ہے اور بدترین صورت میں الجھن۔

اعتماد ہی پروڈکٹ ہے۔ جو کسٹمر اپنا اشتہاری اکاؤنٹ جوڑتا ہے وہ ہمیں اپنی چابیاں سونپ رہا ہوتا ہے۔ اگر انہیں کوئی ایسی چیز ملے جو ہم نے پوچھے بغیر بنائی ہو، تو اگلا سوال یہ ہوتا ہے کہ ہم نے اور کیا کیا ہے۔ خاموشی سے کچھ بنانا سرپرستانہ رویہ محسوس ہوتا ہے، چاہے نیت اچھی ہی کیوں نہ ہو۔

کسی اور کے سسٹم میں غیر متوقع تبدیلیاں مہنگی پڑتی ہیں۔ کسٹمر کا اکاؤنٹ ہماری ملکیت نہیں، اور ہم اس میں ہونے والی ہر دوسری چیز نہیں دیکھ سکتے۔ جو تبدیلی ہماری طرف سے بے ضرر لگتی ہے وہ کسی کے ناموں کے نظام یا رپورٹنگ سے ٹکرا سکتی ہے۔

اس سے سپورٹ اور واپسی آسان ہو جاتی ہے۔ جب کسٹمر نے کوئی چیز جان بوجھ کر ایسی اسکرین کے ذریعے بنائی ہو جس نے انہیں بتایا کہ یہ کس لیے ہے، تو وہ جانتے ہیں کہ یہ کہاں سے آئی۔ اگر وہ اسے واپس لینا چاہیں تو انہیں معلوم ہوتا ہے کہ کیا تلاش کرنا ہے۔ پس منظر کی کارروائی انہیں خود سمجھنے کے لیے چھوڑ دیتی ہے۔

چیزیں بنانے سے آگے

یہی منطق ہر اس کام پر لاگو ہوتی ہے جو کوئی پروڈکٹ کسی بیرونی سسٹم میں کرتی ہے، صرف resources بنانے پر نہیں۔ اشتہاری اکاؤنٹ میں لکھا گیا اخراج بھی کسی اور کے سیٹ اپ میں تبدیلی ہے۔ میری رائے یہ ہے کہ ایسی تبدیلیاں نظر آنی چاہئیں اور ان کا ماخذ معلوم ہونا چاہیے: کسٹمر کو یہ دیکھ سکنا چاہیے کہ کیا کیا گیا، اور یہ کہ یہ ہماری طرف سے تھا۔ یہ میرا ایک اصول ہے، ہماری ہر اسکرین کی تفصیل نہیں۔

اہم نکات

  1. کسٹمر کے بیرونی اکاؤنٹ کو ان کا ہی سمجھیں، چاہے آپ کے پاس اس میں لکھنے کی رسائی ہو۔
  2. ڈیفالٹس پیش کریں، لیکن ہر تخلیق کو جائزے کے ایسے مرحلے کے پیچھے رکھیں جس میں قابلِ ترمیم نام، اس کی جگہ، اس کا مقصد اور تصدیق کا واضح بٹن ہو۔
  3. کسی چیز کو بنانے کے عمل کو ایک تجویز کے طور پر ماڈل کریں جو کسی انسان کی تصدیق کے بعد ہی کارروائی بنے۔
  4. پوچھیں کہ کیا کسٹمر بعد میں یہ تبدیلی دیکھ کر حیران ہوگا۔ اگر ہاں، تو اسے خاموشی سے نہ کریں۔