clickSomo
ClickSomo کھولیں

رابطے اور رضامندی

ایسی فہرست جس کا آپ دفاع کر سکیں، نہ صرف ایسی فہرست جو آپ کے پاس ہے

دس ہزار ای میل پتے تو کوئی بھی رکھ سکتا ہے۔ اصل سوال — جو ریگولیٹر، فراہم کنندہ اور آپ کا اپنا ضمیر تھوڑے مختلف الفاظ میں پوچھتے ہیں — یہ ہے کہ ہر پتہ کہاں سے آیا اور کس بنیاد پر آپ اسے لکھنے کے مجاز ہیں۔ ClickSomo اسے دوبارہ تعمیر کرنے والی چیز کے بجائے محفوظ شدہ حقیقت بنا دیتا ہے۔

شناخت ای میل پتہ ہی ہے

ہر ایڈریس کے لیے فی پروجیکٹ ایک رابطہ، یہ پابندی امید پر نہیں بلکہ ڈیٹابیس پر عائد ہوتی ہے۔ ایڈریس لکھتے وقت نارملائز کیے جاتے ہیں، پڑھتے وقت کبھی نہیں — پڑھتے وقت نارملائز کریں تو یہ پابندی محض ایک زیور بن جاتی ہے جو Anna@ اور anna@ دونوں کو اندر آنے دیتی ہے۔

فون نمبرز، جہاں موجود ہوں، E.164 میں محفوظ کیے جاتے ہیں، لیکن فون نمبر ایک خصوصیت ہے، شناخت نہیں۔ یہاں کوئی شناخت کی نشاندہی کا گراف نہیں، کوئی مرج پروٹوکول نہیں اور نہ مرجز کا آڈٹ ریکارڈ، کیونکہ یہاں ہر رابطہ کسی ایسے ذریعے سے آتا ہے جس کے پاس پہلے سے ایک ایڈریس ہوتا ہے: درآمد، فارم، سبسکرپشن، یا آپ کا اپنا کوڈ۔

نام مکمل محفوظ کیا جاتا ہے

display_name بالکل اسی طرح محفوظ رہتا ہے جیسا دیا گیا تھا اور کبھی حصوں میں تقسیم نہیں کیا جاتا۔ نام کی تقسیم غلطیوں کی کارخانہ ہے — "van der Berg"، "Kim Min-jun"، یک نامی نام، القاب، اور ہر وہ ترتیب جو انگریزی روایت کے مطابق نہ ہو — اور غلط تقسیم مرج ٹیگ میں "Dear van," کی شکل میں سامنے آتی ہے، جو کسی ذاتی نوعیت کے خطاب کے بالکل نہ ہونے سے بھی بدتر ہے۔

منظم حصے صرف ان ذرائع کے لیے موجود ہیں جو انہیں پہلے سے الگ الگ فراہم کرتے ہیں۔ کچھ بھی ان سے اخذ نہیں کیا جاتا۔ اور کوئی نام جو کسی نے خود لکھا ہو، کبھی کسی بعد کی CSV سے نہیں بدلا جاتا جو اتفاقاً کچھ اور نوٹ کرتی ہو، کیونکہ آخری لکھنے والے کی فتح کا اصول سب سے لاپرواہ درآمد کو فتح دلاتا ہے۔

ایک رابطہکیا محفوظ ہے
  • 1شناختای میل، نارملائز شدہ۔ پروجیکٹ کے اندر منفرد۔
  • 2ناممکمل محفوظ کیا جاتا ہے۔ first_name رینڈر کے وقت اخذ کیا جاتا ہے، کبھی محفوظ نہیں کیا جاتا۔
  • 3خصوصیاتجو آپ چاہیں، JSON کی صورت میں۔ آپ کی اپنی، اور attrs.* کے طور پر داخل کی جا سکتی ہیں۔
  • 4ٹیگز اور فہرستیںٹیگز بنیادی حیثیت رکھتے ہیں اور ایک ہی اسٹور میں رہتے ہیں؛ فہرستیں واضح رکنیت ہیں۔
  • 5اجازتہر چینل کے لیے ایک قطار، قانونی بنیاد اور اس کے ثبوت کے ساتھ۔
  • 6واقعاتاس شخص کے کیے ہوئے ہر کام کی صرف اضافے والی لاگ۔ وہ جدول جس پر پورا پروڈکٹ قائم ہے۔
  • ×کبھی نہیںکوئی پاس ورڈ نہیں، کوئی ہیش نہیں، کوئی سیشن نہیں، کوئی API کلید نہیں۔ کسی کو تصدیق کرنے والا کالم حادثہ ہوگا، خصوصیت نہیں۔

ٹیننٹ اور پروجیکٹ، دونوں تک محدود

رضامندی کا رجسٹر

غیر موجودگی اجازت نہیں ہے

ہر رابطے کے لیے ہر چینل کی ایک قطار — ای میل، SMS، خط، پش — ہر ایک میں ایک حالت، ایک قانونی بنیاد، ایک ذریعہ، ثبوت، وقت کے نشانات اور دائرہ اختیار شامل ہوتے ہیں۔ جس رابطے کے پاس کسی چینل کے لیے بنیاد کی قطار نہ ہو، اسے اس چینل پر کچھ بھی نہیں بھیجا جا سکتا۔ نہ "نشان زد ہے"۔ نہیں بھیجا جا سکتا۔

consent

کسی نے خود فعال طور پر درخواست کی۔ فارم جمع کرانا جس کا ثبوت محفوظ ہو، ڈبل آپٹ اِن، یا کوئی چیک باکس جس پر اس نے خود ٹک لگایا۔ یہ سب سے مضبوط بنیاد ہے اور واحد بنیاد ہے جو ایک فارم پیدا کر سکتا ہے۔

legitimate_interest

CSV درآمد کی سب سے بہتر حیثیت یہی ہو سکتی ہے۔ ایک اسپریڈشیٹ کسی کے کسی چیز پر رضامند ہونے کو یاد نہیں رکھ سکتی، اس لیے اسے کبھی ایسا دعویٰ کرنے کی اجازت نہیں — اور وہی فائل دوبارہ اپ لوڈ کرنے سے یہ بنیاد بہتر نہیں ہوتی۔

contract

آپ اس لیے انہیں لکھ رہے ہیں کہ آپ دونوں کسی چیز میں شریک ہیں۔ سروس کی یاد دہانی، تجدید کا نوٹس، وہ چیز جس کے نہ ملنے پر وہ ناراض ہوتے۔

کسی مہم کے بھیجنے سے پہلے، آپ اس کے سامعین کی بنیادوں کا امتزاج دیکھتے ہیں: ان میں سے کتنے لوگوں نے خود درخواست کی، کتنے تک آپ جائز مفاد کے تحت پہنچ رہے ہیں، اور کتنے معاہدے کی بنا پر موجود ہیں۔ یہ ایک ایسا عدد ہے جس نے کسی بھی انتباہی بینر سے زیادہ بری مہمیں روکی ہیں۔

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

فہرست کی ہر قطار کے پیچھے کسی نے ہاں کہی تھی۔

چار راستے

آپ کی فہرست میں داخل ہونے کا ہر راستہ آپ ہی ہیں، اپنے اپنے ڈیٹا پر عمل کرتے ہوئے

کوئی سروس ٹوکن کی انجیسٹ لین نہیں ہے اور نہ کوئی ہم منصب پروڈکٹ خاموشی سے آپ کے رابطوں میں لکھتا ہے۔ اگر آپ کسی کو فہرست میں شامل کرنا چاہتے ہیں، تو ان چار میں سے کوئی ایک راستہ اسے وہاں پہنچاتا ہے۔

CSV درآمد

کالم بہ کالم میپ کیا جاتا ہے، لکھتے وقت نارملائز کیا جاتا ہے، MX چیک کیا جاتا ہے تاکہ مردہ اور غلط لکھے گئے ڈومینز سخت باؤنس سے پہلے پکڑے جائیں، اور ایک واضح بنیاد کے ساتھ داخل کیا جاتا ہے جو آپ خود مقرر کرتے ہیں۔ درآمد کو ایک شناخت ملتا ہے، اور اس سے بنے ہر رابطے کا حوالہ اسی کی طرف واپس جاتا ہے۔

ایک ClickSomo فارم

باقی سب کی طرح اسی دستاویز سے رینڈر کیا جاتا ہے، توثیق، ہنی پاٹ اور ریٹ لمٹ کے ساتھ۔ فارم جمع کرانا واحد راستہ ہے جو جائز طور پر consent پیدا کر سکتا ہے، کیونکہ یہی واحد راستہ ہے جہاں شخص خود موجود ہوتا ہے۔

ایک صفحہ جو آپ نے dash-b میں بنایا

ڈیش بورڈ ڈیزائنر صفحات شائع کرتا ہے؛ ان میں سے کسی ایک پر موجود فارم آپ کے اپنے اسناد کے ساتھ یہاں پوسٹ کرتا ہے۔ وہی توثیق، وہی اجازت کا نظام، کوئی دوسرا انٹیگریشن برقرار رکھنے کی ضرورت نہیں۔

عوامی API

POST /v1/contacts آپ کے اپنے ٹوکن کے ساتھ، اپسرٹ سیمنٹکس، اور idempotency key کی پاسداری۔ آپ کی ایپ پہلے ہی جانتی ہے کہ کس نے سائن اپ کیا؛ یہ اسی حقیقت سے فنل تک کا مختصر ترین راستہ ہے۔

سیگمنٹس ایک مُقررہ شرط (predicate) ہیں، مرتب شدہ

سیگمنٹ ایک محفوظ کردہ شرطی درخت ہے جو رابطوں کے حقول، خصوصیات، ٹیگز، فہرست کی رکنیت اور رویے پر مشتمل ہوتا ہے، جسے SQL میں مرتب کیا جاتا ہے اور ایک شمار کے ساتھ کیش کیا جاتا ہے۔ آپریٹرز عام قسم کے ہیں — برابر، برابر نہیں، میں شامل، شامل نہیں، سے شروع ہوتا ہے، پر ختم ہوتا ہے، پر مشتمل، مقرر ہے، مقرر نہیں — جو آپ کی ضرورت کے مطابق کسی بھی گہرائی تک and، or اور not کے ساتھ ملائے جاتے ہیں۔

استعمال سے پہلے اس کا پیش نظارہ کریں۔ یہ اینڈ پوائنٹ حقیقی رابطے واپس کرتا ہے، اس لیے کہ "اس میں اصل میں کون ہے" یہ سوال آپ دیکھ کر جواب دیتے ہیں، بھیج کر معلوم کرنے کے بجائے۔

سیگمنٹس پھر دوہرا کام کرتے ہیں: مہم کے لیے سامعین کے طور پر، فنل برانچ کی شرط کے طور پر، اور خود اپنے آپ میں محرک (trigger) کے طور پر — segment_enter اس لمحے ایک رن شروع کر دیتا ہے جب کوئی شخص اہل ہو جاتا ہے۔

خاموش باقاعدہ افرادسیگمنٹ پیش نظارہ · 412
  • 1ٹیگtags contains "regular"
  • 2خاصیتattrs.total_orders >= 3 — آپ کا حقل، اس کے لیے آپ کا نام۔
  • 3طرز عملپچھلے 90 دنوں میں کوئی order.paid ایونٹ نہیں۔
  • 4رضامندیایک قابلِ استعمال ای میل بنیاد۔ جو رابطے ایسی بنیاد نہیں رکھتے وہ شمار میں شامل نہیں، کیونکہ انہیں بہرحال بھیجا نہیں جا سکتا۔
  • iپیش نظارہ412 رابطے، درج شدہ۔ بھیجنے کے وقت دوبارہ شمار کیا جائے گا، کیونکہ سیگمنٹ ایک سوال ہے، اسنیشٹ نہیں۔

SQL میں مرتب شدہشمار کیش شدہ، جواب براہِ راست

روک تھام (suppression)، اور اس کی جانچ کب ہوتی ہے

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

یہ دوسری جانچ اصل کام کرتی ہے۔ تین دن کے انتظار والے فنل میں تین دن کی ایک ایسی سہولت ہوتی ہے جس میں کوئی شخص ان سبسکرائب کر سکتا ہے، اور جو نظام پیغام قطار میں لگتے ہی روک تھام کی جانچ کر لے وہ پھر بھی اسے میل بھیج دے گا۔ بھیجنے کے وقت جانچ، ان سبسکرائب کا احترام اور صرف اس کا اندراج — ان کے درمیان فرق ہے۔

مٹانا بھی اسی طرح کام کرتا ہے: حذف کرنے کی درخواست یہاں رابطہ اور اس کے پیغامات کی تاریخ ہٹا دیتی ہے، اور اسی اندرونی راستے سے جو باقی خاندان استعمال کرتا ہے، ہر ہم پلہ سروس تک پہنچتی ہے جس کے پاس نقل موجود تھی۔ پوچھنے کی ایک جگہ ہے اور ہونے والی ایک چیز ہے۔