iOS 27 Apple-কে, এবং ক্রমবর্ধমান একটি আঞ্চলিক আইনের তালিকাকে, একটি formal উপায় দেয় যাতে আপনার app কোনো ডেটা সংগ্রহ করার আগেই ব্যবহারকারীর বয়স জানতে পারে। আপনার app যদি মাইনরদের কাছ থেকে কিছু সংগ্রহ করে, আর বেশিরভাগ কনজিউমার app-ই তা করে এই কথাটা এভাবে না ভেবেই, তাহলে আপনি কীভাবে সম্মতি চাইছেন এবং কী সংগ্রহ করছেন তা কীভাবে ডকুমেন্ট করছেন — সেটা বদলাতে হবে। কোনো একদিন নয়। ক্রমবর্ধমান একটি অঞ্চলের তালিকার জন্য, এখনই।
যেহেতু এটি একটি কমপ্লায়েন্স বিষয়, শুরুতেই একটি কথা বলে রাখি: এই লেখাটি মার্কেটিং ও প্রোডাক্ট টিমের জন্য একটি প্র্যাকটিক্যাল ওরিয়েন্টেশন, এটি কোনো আইনি পরামর্শ নয়। আপনার ব্যবহারকারীরা কোথায় আছেন এবং আপনার app কী করে, তার উপর নির্ভর করে আপনার দায়িত্ব — নির্দিষ্ট বিষয়গুলোতে একজন আইনজীবীর অনুমোদন দরকার। এই গাইড দেখায় iOS 27 কী নতুন নিয়ে এসেছে, আপনার বর্তমান ট্র্যাকিং ও সেগমেন্টেশনের জন্য এর মানে কী, আর App Store-এর গেট আরও কড়া হওয়ার আগে কাজ করার একটি চেকলিস্ট। Pushwoosh একটি কাস্টমার এনগেজমেন্ট প্ল্যাটফর্ম, আর যেখানে সম্মতি ও ডেটা সংগ্রহ আপনার Pushwoosh সেটআপকে ছুঁয়ে যায়, আমরা ঠিক সেই জায়গাটি দেখিয়ে দিই।
এটি সম্পূর্ণ iOS 27 রাউন্ডআপ-এর একটি অংশ। একই ভিত্তিকে অন্যভাবে দেখতে: ডিভাইস ক্যাপাবিলিটি অনুযায়ী ভাগ করা।
iOS 27 আসলে কী নিয়ে আসছে
এর কেন্দ্রে আছে দুটি API, আর এরা একসাথে কাজ করে।
Declared Age Range API আপনার app-কে একজন ব্যবহারকারীর age band জানতে দেয়, যেমন 13+, 16+, বা 18+, কখনো জন্মতারিখ না চেয়ে বা সংরক্ষণ না করে। Apple সেই band দেয়; আপনি পান একটি সিগন্যাল, কোনো তারিখ নয়। এই ফ্রেমওয়ার্ক iOS 26 থেকেই আছে, আর iOS 27-এ এর চারপাশের requirement এবং enforcement আরও কড়া হচ্ছে।
PermissionKit পিতামাতার সম্মতির অংশটি সামলায়। আপনার app যখন এমন কোনো বড় পরিবর্তন আনে যা একজন মাইনরের ব্যবহারকে প্রভাবিত করে, তখন PermissionKit-ই সেই flow যা ব্যবহারকারীকে জানায়, আর regulated অঞ্চলে, মাইনর এগিয়ে যাওয়ার আগে একজন অভিভাবকের অনুমোদন চায়।
সবচেয়ে গুরুত্বপূর্ণ ডিজাইন বিষয়টি হলো: system নিজেই আপনাকে বলে দেয় কখন এটা প্রযোজ্য। isEligibleForAgeFeatures এবং requiredRegulatoryFeatures-এর মতো সিগন্যালের মাধ্যমে, OS জানিয়ে দেয় কোনো নির্দিষ্ট ব্যবহারকারীর ক্ষেত্রে বয়স-সংক্রান্ত বাধ্যবাধকতা প্রযোজ্য কিনা, এবং আপনার age range বা parental consent চাওয়া দরকার কিনা। আপনাকে প্রতিটি ব্যবহারকারীর জন্য অনুমান করতে হচ্ছে না — প্ল্যাটফর্মই সরাসরি সেই applicability দিয়ে দিচ্ছে।
“সেপ্টেম্বরে বাধ্যতামূলক” শিরোনামগুলো যা ভুল বলছে
এখানে নির্দিষ্ট হওয়া জরুরি, কারণ এই বাধ্যবাধকতা কোনো একক গ্লোবাল সুইচ নয়, আর “সেপ্টেম্বরে বাধ্যতামূলক” — Apple নিজে এই কথাটা আসলে বলে না। এখানে দুটো আলাদা বিষয় চলছে, আর মিডিয়া কভারেজ এগুলোকে একটি মাত্র deadline-এ মিশিয়ে ফেলে।
প্রথমটি হলো App Store review gate। Apple ক্রমাগত কড়া করছে আপনার প্রাইভেসি ডকুমেন্টেশন এবং বয়স-হ্যান্ডলিং কী দেখাতে হবে সে বিষয়ে, আর social বা user-generated-content ফিচার থাকা app-গুলোর কাছে প্রত্যাশা করা হয় যে তারা Declared Age Range API-এর উপর ভিত্তি করে একটি ব্যবহারকারী-মুখী age gate implement করবে। এটা পুরো iOS 27 সাইকেল জুড়ে ধীরে ধীরে কড়া হয়, কোনো একটি নির্দিষ্ট সকালে চালু হয় না — তবে আপনার app-এ social ফিচার থাকলে, এটাকে আপনার পরবর্তী রিলিজের আগে শেষ করার কাজ হিসেবে ধরুন, পরে নয়।
দ্বিতীয়টি, যার নির্দিষ্ট deadline আছে, তা হলো আঞ্চলিক আইন, আর এটি ইতিমধ্যেই বেশ কিছু জায়গায় কার্যকর। Apple নিজেই Declared Age Range-এর বাধ্যবাধকতাকে নির্দিষ্ট এখতিয়ারের সাথে যুক্ত করে: Utah-তে নতুন Apple Account-এর জন্য age category শেয়ার করা হচ্ছে 6 মে, 2026 থেকে এবং Louisiana-তে 1 জুলাই, 2026 থেকে, আর Apple অস্ট্রেলিয়া, ব্রাজিল ও সিঙ্গাপুরে 18+ ডাউনলোড ব্লক করা শুরু করেছে 24 ফেব্রুয়ারি, 2026 থেকে। অন্যান্য আইন নিজেদের timeline অনুযায়ী চলছে, কিছু ইতিমধ্যে কার্যকর, কিছু পিছিয়ে গেছে। system-এর regulatory সিগন্যালগুলো ঠিক এই কারণেই আছে — কারণ “এই ব্যবহারকারীর জন্য আমাকে এটা করতে হবে কিনা” প্রশ্নের উত্তর নির্ভর করে তার অঞ্চল এবং সেই অঞ্চলের আইনের বর্তমান অবস্থার উপর।
practical অর্থে বললে: আপনার যদি social বা UGC ফিচার থাকে, বা কোনো regulated অঞ্চলে মাইনরদের কাছ থেকে ডেটা সংগ্রহ করেন, তাহলে এটা এখনকার কাজ, ভবিষ্যতের কোনো item নয়। যদি এখনও দুটোর একটাও প্রযোজ্য না হয়, তারপরও প্রাইভেসি ডকুমেন্টেশন আপ টু ডেট রাখা প্রত্যাশিত, আর আঞ্চলিক মানচিত্র ক্রমশ বড় হচ্ছে — তাই এখনই এই সক্ষমতা তৈরি করা পরে deadline-এর চাপে ঠিক করার চেয়ে সস্তা।
এটা মার্কেটিং-এ কেন এসে পড়ে, শুধু লিগ্যাল-এ নয়
বয়স যাচাই শুনতে একটা লিগ্যাল-ও-ইঞ্জিনিয়ারিং কাজ মনে হয়, যতক্ষণ না আপনি দেখেন এটা কোথায় গিয়ে ছোঁয়। তখন এটা একদম গিয়ে পড়ে আপনার ট্র্যাকিং এবং সেগমেন্টেশনের উপর।
আপনি যদি advertising identifier সংগ্রহ করেন, automatic behavioral event ফায়ার করেন, বা in-app activity-এর উপর segment তৈরি করেন, তাহলে একটি age সিগন্যাল বদলে দেয় আপনি কী সংগ্রহ করতে পারবেন আর কার সম্পর্কে। protected age band-এর একজন ব্যবহারকারীকে আপনি চুপচাপ একজন প্রাপ্তবয়স্কের মতো একই behavioral tracking আর ad-ID সংগ্রহে ঢুকিয়ে দিতে পারেন না। যে মুহূর্তে OS আপনাকে বলতে পারে কোনো regulated অঞ্চলে একজন ব্যবহারকারী মাইনর, “আমরা সবাইকে একইভাবে ট্র্যাক করি” আর একটা defensible default থাকে না।
অনেক app যে একটি gap বহন করে চলেছে, তা বন্ধ করারও এটাই সময়: advertising identifier (iOS-এ IDFA, Android-এ GAID) নিয়ে অস্পষ্ট বা undocumented হ্যান্ডলিং। আপনার ডেটা ডকুমেন্টেশন যদি স্পষ্টভাবে না বলে আপনি কোন advertising identifier সংগ্রহ করছেন এবং কেন, তাহলে সেই gap আগে থেকেই একটি ঝুঁকি ছিল। iOS 27 সাইকেল জুড়ে review gate কড়া হওয়ার সাথে সাথে, এটা rejection-এর ঝুঁকি হয়ে ওঠে। age-collection-এর গল্প আর ad-ID ডকুমেন্টেশন একসাথে ঠিক করাটাই efficient পদক্ষেপ, কারণ দুটোই একই প্রাইভেসি ডিসক্লোজারে থাকে।
নিশ্চিত না আপনার স্ট্যাক প্রতিটি ব্যবহারকারী সম্পর্কে কী ধরে রাখে? আমাদের কাস্টমার ডেটা FAQ দিয়ে শুরু করুন।
আপনার কমপ্লায়েন্স চেকলিস্ট
আপনার লিগ্যাল ও ইঞ্জিনিয়ারিং পার্টনারদের সাথে এগুলো নিয়ে কাজ করুন:
- আপনার মাইনররা কোথায় আছে তা ম্যাপ করুন। চিহ্নিত করুন আপনি কোন কোন অঞ্চলে কাজ করেন যেখানে age-assurance আইন এখনই কার্যকর, আর আপনার app-এ কি social বা UGC ফিচার আছে যা অঞ্চল যাই হোক না কেন App Store gate ট্রিগার করে।
- applicability সিগন্যাল গ্রহণ করুন। নিজের অনুমান তৈরি না করে, OS-এর সেই সিগন্যালগুলো ব্যবহার করুন যা বলে দেয় কোনো নির্দিষ্ট ব্যবহারকারীর ক্ষেত্রে age বাধ্যবাধকতা প্রযোজ্য কিনা। প্ল্যাটফর্মকেই বলতে দিন কখন age range বা consent চাইতে হবে।
- age range চান, জন্মতারিখ নয়। যেখানে আপনার age সিগন্যাল দরকার, সেখানে Declared Age Range API ব্যবহার করুন যাতে আপনি একটি band পান আর কখনো এমন জন্মতারিখ সংগ্রহ বা সংরক্ষণ না করতে হয় যা পরে আপনাকে সুরক্ষিত রাখতে হবে।
- বড় পরিবর্তনের জন্য parental consent সংযুক্ত করুন। যদি মাইনররা আপনার app ব্যবহার করে, নিশ্চিত করুন যেসব অঞ্চলে এটা দরকার সেখানে significant-change consent flow প্রস্তুত আছে।
- age band অনুযায়ী ট্র্যাকিং সেগমেন্ট করুন। নিশ্চিত করুন protected age band-এর ব্যবহারকারীরা advertising-ID সংগ্রহ এবং মাইনরদের জন্য অনুমোদিত নয় এমন behavioral tracking থেকে বাদ পড়ছেন। এটি একটি ডেটা সংগ্রহ এবং সম্মতি কনফিগারেশন, প্রতিটি ব্যবহারকারীর জন্য ম্যানুয়াল রিভিউ নয়।
- আপনার প্রাইভেসি ডকুমেন্টেশন আপডেট করুন। আপনার App Store প্রাইভেসি ডিসক্লোজার আপ টু ডেট করুন, আর সেই সাথে advertising-ID ডকুমেন্টেশন গ্যাপ বন্ধ করুন যাতে IDFA আর GAID হ্যান্ডলিং স্পষ্টভাবে বলা থাকে। review gate সবার আগে এটাই চেক করে।
- আপনার consent copy রিভিউ করুন। নিশ্চিত করুন একজন মাইনর বা অভিভাবক যে consent ভাষা দেখেন তা আপনি আসলে কী সংগ্রহ করেন তার সাথে মেলে, ঠিক আপনার GDPR consent practice-এর মতো একই মানসিকতায়।
Pushwoosh দিয়ে age-aware ডেটা সংগ্রহ পরিষ্কারভাবে সামলান
Pushwoosh আপনাকে consent management এবং data-collection কন্ট্রোল দেয়, যাতে আপনি age band অনুযায়ী ট্র্যাকিং সেগমেন্ট করতে পারেন, protected ব্যবহারকারীদের এমন সংগ্রহ থেকে বাদ দিতে পারেন যেখানে তাদের থাকা উচিত নয়, আর আপনার advertising-ID হ্যান্ডলিং ডকুমেন্টেড ও পরিষ্কার রাখতে পারেন। Pushwoosh SOC 2 Type I এবং ISO 27001:2022 সার্টিফায়েড, GDPR এবং HIPAA সম্মত, আর EU ও US-এ ডেটা সেন্টার পরিচালনা করে — প্রতিটি প্ল্যানে এন্টারপ্রাইজ-গ্রেড নিরাপত্তা। কমপ্লায়েন্সের কাজ কখনোই zero effort হয় না, কিন্তু ডেটার দিকটা তার সবচেয়ে কঠিন অংশ হওয়া উচিত নয়।
সাধারণ জিজ্ঞাসা
সম্পর্কিত আর্টিকেল
সব দেখুন