Substack থেকে beehiiv: ভুল CSV-তে subscriber হারানোর আগে এই audit করুন
Substack থেকে beehiiv-এ subscriber ও পুরোনো post অক্ষত রাখার সবচেয়ে নিরাপদ পদ্ধতি হলো migration-কে কয়েকটি যাচাইযোগ্য ধাপে ভাগ করা: untouched backup, CSV audit, field mapping, content ও paid-access পরীক্ষা, সীমিত test send, তারপর domain ও billing cutover। ভুল CSV সরাসরি Substack-এর পাঠক মুছে দেয় না, কিন্তু বাদ পড়া row, ভুল field কিংবা অনুপযুক্ত status নিয়ে import করলে beehiiv-এর audience অসম্পূর্ণ হতে পারে।
প্রথমে Substack-এর পূর্ণ archive ZIP এবং subscriber CSV আলাদা করে সংরক্ষণ করুন। Substack-এর archive export নির্দেশনা অনুযায়ী publication Settings-এর Exports থেকে post, subscriber list ও সংশ্লিষ্ট statistics-সহ ZIP তৈরি করা যায়। এই মূল ZIP বা CSV সম্পাদনা করবেন না; পরিষ্কার করা import file হবে তার আলাদা copy।
১. Export-এর আগে source-of-truth তৈরি করুন
একই সময়ে dashboard ও export থেকে একটি baseline লিখে রাখুন। মোট subscriber-এর পাশাপাশি free, paid এবং complimentary, gifted বা iOS access থাকলে সেগুলো আলাদা ধরুন; content-এর ক্ষেত্রে মোট post ও paywalled post-এর হিসাব রাখুন। Export-এর পরে আসা signup, cancellation বা plan change একটি পৃথক delta তালিকায় লিখলে পরবর্তী অমিলকে data loss বলে ভুল করার আশঙ্কা কমে।
একটি migration folder-এ original ZIP, original CSV, cleaned CSV এবং reconciliation sheet আলাদা নামে রাখুন। প্রতিটি cleaned file-এর row count, তৈরির সময় এবং কোন import-এ সেটি ব্যবহৃত হয়েছে লিখে রাখুন। Subscriber ও content যাচাই শেষ হওয়ার আগে Substack publication, custom domain বা billing বন্ধ করবেন না—rollback-এর জন্য source system সচল থাকা দরকার।
- Original export কখনো overwrite করবেন না।
- Free, paid ও বিশেষ-access পাঠকের count আলাদা রাখুন।
- প্রতিটি বাদ দেওয়া বা একীভূত করা row-এর কারণ লিখুন।
- Export-এর পরের পরিবর্তনগুলো delta হিসেবে মেলান।
২. CSV audit-এ email, status ও duplicate একসঙ্গে দেখুন
Substack-এর email-list export নথি বলছে Subscribers পেজের All subscribers থেকে all columns অথবা visible columns-সহ CSV নেওয়া যায়; all-columns export-এ open ও post-view সম্পর্কিত field থাকতে পারে, আর visible-columns export নির্বাচিত filter অনুসরণ করে। একই নথি অনুযায়ী subscriber-এর পূর্ণ নাম বর্তমানে export করা যায় না, তাই name না থাকাকে ব্যর্থ export ধরে নেবেন না।
Working copy-তে ফাঁকা email, শুরু বা শেষে whitespace, ভাঙা header এবং একই email-এর একাধিক row খুঁজুন। Duplicate পেলেই একটি row মুছে দেবেন না: plan, expiry, signup date বা segmentation data আলাদা হলে আগে একটি canonical record বানিয়ে কোন মান রাখা হলো তা reconciliation sheet-এ লিখুন। এতে row কমলেও পরিবর্তনের ব্যাখ্যা থাকবে এবং দরকারে original থেকে মান ফেরানো যাবে।
Filtered export ব্যবহার করলে filter ও exported row count নথিভুক্ত করুন। Unsubscribed, suppressed বা অন্যভাবে পাঠানো-অনুপযুক্ত contact-কে অনুমান করে active বানাবেন না; আবার status অস্পষ্ট হলে তাকে নীরবে বাদও দেবেন না। সন্দেহজনক row আলাদা review file-এ রাখুন এবং import batch-এ কেবল সেই contact নিন, যার বর্তমান status ও email পাওয়ার সম্মতি ব্যাখ্যা করা যায়।
৩. beehiiv mapping ও importer-এর সীমা আগে বুঝুন
beehiiv-এর official migration workflow CSV upload-এর পরে column-to-field mapping ও নতুন custom field তৈরির সুযোগ দেয়; country field-কে subscriber_country-এর মতো নামে বদলাতে বলে, import-এর পরে original signup date রাখতে Support-এর সহায়তার কথা জানায় এবং activity rating শূন্য free subscriber-কে প্রথম দুই থেকে চার সপ্তাহ send থেকে বাদ রাখার সুপারিশ করে। একই নির্দেশিকায় free content-এর জন্য Substack publication URL, free ও paywalled content একসঙ্গে আনতে original export ZIP, paid tier আগেই তৈরি ও map করা, migration-এর পরে double billing ঠেকাতে Substack billing pause বা cancel করা এবং complimentary, gifted ও iOS access আলাদাভাবে সামলানোর ধাপ রয়েছে।
Upload-এর আগে mapping table বানান: Substack header, beehiiv destination field, data type এবং একটি sample value—এই চারটি column যথেষ্ট। একই অর্থের দুটি custom field তৈরি করবেন না; যেমন source ও acquisition_source আলাদা রাখার কারণ না থাকলে একটি canonical নাম বেছে নিন। Date field-এর format এবং শূন্য, blank ও text value কীভাবে ধরা হচ্ছে, sample row দিয়ে পরীক্ষা করুন।
পুরো list দিয়ে শুরু না করে একটি representative batch ব্যবহার করা সম্পাদকীয়ভাবে নিরাপদ। তাতে free, paid, পুরোনো ও নতুন signup এবং custom data-সহ কয়েক ধরনের record রাখুন। Import শেষে accepted ও rejected count লিখে প্রত্যেক ধরনের একটি subscriber profile খুলুন; email, tier, custom fields ও date প্রত্যাশামতো না এলে mapping সংশোধন করে নতুন version-এর CSV তৈরি করুন।
৪. Post count নয়, content ও access মিলিয়ে দেখুন
Content import complete দেখালেই archive যাচাই শেষ নয়। পুরোনো, মাঝামাঝি ও সাম্প্রতিক সময় থেকে নমুনা post বেছে title, publish date, heading, paragraph, image, link এবং web version দেখুন। Video, podcast, photo gallery, comments, category এবং code block থাকা post আলাদা তালিকায় রাখুন, কারণ importer-এর ঘোষিত সীমাবদ্ধতা এসব content type-এ প্রভাব ফেলতে পারে।
Paid archive-এর জন্য অন্তত একটি পুরো paywalled post এবং একটি preview-সহ post পরীক্ষা করুন। Free account দিয়ে restriction এবং paid account দিয়ে সম্পূর্ণ access খুলছে কি না দেখুন; preview প্রয়োজন হলে beehiiv-এ paywall placement পুনর্গঠন করুন। Paid tier বা Stripe setup ছাড়া import চালানোর আগে বিশেষ সতর্ক থাকুন, কারণ ভুল configuration-এ gated content-এর দৃশ্যমানতা বদলে যেতে পারে।
Reconciliation sheet-এ source post count, imported count, unsupported বা manually recreated item এবং ব্যর্থ import আলাদা column-এ রাখুন। দুই platform-এর মোট সংখ্যা সমান হওয়া একটি signal মাত্র; sample post-এর content ও access ঠিক না থাকলে সেই count migration সফল প্রমাণ করে না।
৫. Test send পাস হলে domain ও billing cutover করুন
Domain বদলানোর আগে নিজের নিয়ন্ত্রিত address-এ internal test পাঠান। Sender name, reply-to, বাংলা লেখা, link, unsubscribe control এবং mobile rendering পরীক্ষা করে তারপর সম্মতিপ্রাপ্ত active subscriber-এর ছোট segment-এ একটি বাস্তব send চালান। এটি official import step নয়, বরং mapping ও delivery সমস্যা পুরো audience-এ ছড়ানোর আগে ধরার সতর্কতামূলক audit।
Test-এর পরে beehiiv audience count-কে cleaned CSV row count-এর সঙ্গে সরাসরি সমান ধরে নেবেন না। হিসাবটি লিখুন: cleaned rows থেকে duplicate, invalid বা rejected record এবং ইচ্ছাকৃত exclusion বাদ দিলে imported total পাওয়া উচিত। পার্থক্যের ব্যাখ্যা না পাওয়া পর্যন্ত পরের batch বা full-list send স্থগিত রাখুন।
Subscriber reconciliation, archive sample, paid access এবং test send—চারটি pass করার পরেই custom domain বা DNS বদলান। বিদ্যমান DNS record-এর backup রাখুন এবং switch-এর পরে গুরুত্বপূর্ণ পুরোনো post URL ও landing page খুলে দেখুন। Paid publication হলে tier ও legacy price mapping এবং migrated access নিশ্চিত করার পরে Substack billing pause বা cancel করুন; complimentary, gifted ও iOS subscriber-এর completion আলাদা করে মেলান।
Migration সম্পূর্ণ তখনই, যখন প্রতিটি count difference-এর লিখিত ব্যাখ্যা আছে, content ও paid access যাচাই হয়েছে এবং untouched export অক্ষত রয়েছে। এই audit subscriber হারানোর অদৃশ্য পথ—বাদ পড়া row, ভুল status, ভাঙা field mapping ও অসম্পূর্ণ paid access—domain switch-এর আগেই শনাক্ত করার সুযোগ দেয়।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।