VOD অ্যানালিটিক্স ও খরচ

গল্পে বুঝি

যাত্রাবাড়ীতে খোয়ারিজমির একটা রিকশা গ্যারেজ, চল্লিশটা রিকশা। গ্যারেজের দেয়ালে ঝোলে একটা মোটা খাতা। প্রতিদিন সকালে কে কোন রিকশা নিল, সন্ধ্যায় কখন ফেরত দিল, কত টাকা জমা দিল, সব লেখা হয়। শুরুতে খোয়ারিজমি শুধু গুনত “আজ কয়টা রিকশা বের হলো”, কিন্তু একদিন দেখল ত্রিশটা বের হয়েছে অথচ জমা কম। খাতা ঘেঁটে বোঝা গেল অর্ধেক রিকশা দশ মিনিট পরই ফেরত এসেছে, চাকা পাংচার বলে। “বের হওয়া” গোনা ভুল মাপ; আসল প্রশ্ন ছিল “কতক্ষণ রাস্তায় চলল”।

খরচের পাতাটা আরও শিক্ষণীয়। প্রতি মাসে তিন রকম খরচ: নতুন রিকশা বানানো বা রং করা (একবারের বড় খরচ), গ্যারেজের ভাড়া (রিকশা চলুক না চলুক, জায়গা নিলেই দিতে হয়), আর প্রতিদিনের মেরামত ও টায়ার (যত চলবে তত খরচ)। খোয়ারিজমি হিসাব করে দেখল সবচেয়ে বড় খরচ মেরামত, কারণ সেটা চলার সাথে বাড়ে। আর গ্যারেজের কোণে পাঁচটা পুরনো রিকশা দুই বছর ধরে পড়ে আছে, কেউ চালায় না, কিন্তু জায়গার ভাড়া খাচ্ছে। সে ওগুলো বিক্রি করে দিল। আর চালকদের জন্য সে ভাড়ার তালিকা গ্যারেজের গেটে টাঙিয়ে রাখে, দিনের ভাড়া কত, দেরিতে ফেরালে কত; কেউ সন্ধ্যায় এসে “লুকানো চার্জ” দেখে অবাক হয় না।

মিলিয়ে নিই: “কয়টা রিকশা বের হলো” হলো কাঁচা প্লে কাউন্ট, আর “কতক্ষণ রাস্তায় চলল” হলো ওয়াচ টাইম; দশ মিনিটে ফেরত আসা রিকশা হলো প্রথম কয়েক সেকেন্ডে ছেড়ে দেওয়া ভিউ, যেগুলো আলাদা করে না দেখলে এনগেজমেন্ট কার্ভ ভুল পড়বেন। নতুন রিকশা বানানো হলো এনকোডিং খরচ (একবার, আপলোডের সময়), গ্যারেজ ভাড়া হলো স্টোরেজ খরচ (দেখা হোক না হোক, প্রতি মাসে), আর মেরামত হলো ডেলিভারি বা ইগ্রেস খরচ (যত দেখা হবে তত), যেটা সাধারণত সবচেয়ে বড়। কোণে পড়ে থাকা রিকশা হলো কেউ দেখে না এমন রেন্ডিশন, যা মুছে ফেলা বা সস্তা টায়ারে সরানো যায়। আর গেটে টাঙানো ভাড়ার তালিকা হলো নিজের ক্রেতাদের জন্য স্বচ্ছ প্রাইসিং। বাস্তবে প্রতিটা VOD প্ল্যাটফর্ম ঠিক এই খাতা চালায়, আর লাভ-ক্ষতি নির্ভর করে এই তিনটা খরচের অনুপাত কতটা ঠিকঠাক মাপা হচ্ছে তার উপর।

আগে সংজ্ঞা: একটা “ভিউ” কী

অ্যানালিটিক্সের সবচেয়ে বেশি ঝগড়া হয় সংজ্ঞা নিয়ে। ক্রেতা বলে “আমার ড্যাশবোর্ডে এক হাজার ভিউ, আপনার বিলে দুই হাজার”, আর দুজনেই ঠিক, কারণ দুজন আলাদা জিনিস গুনছে। তাই সংজ্ঞা লিখে রাখুন আর ডকসে প্রকাশ করুন:

শব্দ	এই প্ল্যাটফর্মের সংজ্ঞা (উদাহরণ)
প্লেব্যাক সেশন	একটা প্লেয়ার ইনস্ট্যান্স একটা asset লোড করা থেকে বন্ধ হওয়া পর্যন্ত, একটা sid
ভিউ	এমন একটা সেশন যেখানে প্রথম ফ্রেম দেখানো হয়েছে (প্লে চাপার পর স্টার্টআপ সফল)
কোয়ালিফায়েড ভিউ	এমন ভিউ যেখানে অন্তত ৩০ সেকেন্ড বা ভিডিওর ২৫% (যেটা কম) দেখা হয়েছে
ওয়াচ টাইম	সেশনে আসলে চলা সময়ের যোগফল; পজ, বাফারিং আর সিক বাদ
ইউনিক ভিউয়ার	নির্দিষ্ট দিনে ভিন্ন ভিউয়ার আইডি; লগইন না থাকলে প্রতি ডিভাইসের একটা র‍্যান্ডম আইডি
কমপ্লিশন	ভিডিওর ৯০% বা বেশি সময় দেখা হয়েছে (শেষের ক্রেডিট বাদ দিতে ১০০% নয়)

দুটো সূক্ষ্ম জিনিস:

• অটোপ্লে আলাদা গুনুন। মিউটেড অটোপ্লে করা ফিড ভিডিও আর ইউজারের চাপ দিয়ে চালানো ভিডিও একই “ভিউ” নয়। ইভেন্টে autoplay: true/false রাখুন।
• লুপ আর রিপ্লে। একই সেশনে শেষ থেকে আবার শুরু করলে নতুন ভিউ নাকি একই? যেটাই বেছে নিন, লিখে রাখুন।

ইভেন্ট: প্লেয়ার কী পাঠাবে

ভিউ আর ওয়াচ টাইম আসে প্লেয়ারের পাঠানো ইভেন্ট থেকে, সার্ভার লগ থেকে নয়। CDN লগ বলে কোন সেগমেন্ট ডাউনলোড হয়েছে, কিন্তু প্লেয়ার আগেভাগে বাফার করে, তাই ডাউনলোড মানে দেখা নয়। প্লেয়ার ইভেন্টের পুরো ডিজাইন আর QoE মেট্রিক (স্টার্টআপ টাইম, রিবাফার) আছে প্লেয়ার অ্যানালিটিক্স চ্যাপ্টারে; এখানে শুধু বিজনেস মেট্রিকের জন্য যা লাগে:

{
  "sid": "sess_9f3c",
  "viewer": "vw_k2P8",
  "tenant": "tnt_baytalhikma",
  "asset": "ast_8Hn2c",
  "event": "heartbeat",
  "ts": "2026-10-25T09:14:30.120Z",
  "position_ms": 412000,
  "played_ms_since_last": 10000,
  "autoplay": false,
  "country": "BD",
  "device": "android"
}

heartbeat প্রতি দশ সেকেন্ডে, সাথে start, pause, seek, ended, error। played_ms_since_last হলো আসলে চলা সময়, প্লেয়ারের timeupdate থেকে হিসাব, তাই পজ আর বাফারিং এমনিতেই বাদ পড়ে। পজিশন পাঠান বলে এনগেজমেন্ট কার্ভ বানানো যায়।

কোথায় রাখবেন

ইভেন্ট অনেক: একটা দশ মিনিটের ভিউ মানে ষাটটা হার্টবিট। দিনে এক লাখ ভিউ মানে ষাট লাখ সারি। দুটো পথ:

• PostgreSQL — শুরুতে, দিনে কয়েক লাখ ইভেন্ট পর্যন্ত, তারিখ অনুযায়ী পার্টিশন করা টেবিল আর প্রতি ঘণ্টায় rollup টেবিলে যোগফল। আলাদা সিস্টেম চালাতে হয় না।
• ClickHouse — যখন rollup কুয়েরি ধীর হয় বা ক্রেতারা নিজের ড্যাশবোর্ডে ইচ্ছামতো ফিল্টার চায়। কলাম-ভিত্তিক স্টোর, কম্প্রেশন ভালো, আর এই ধরনের “গুনো আর যোগ করো” কুয়েরিতে খুব দ্রুত। সেলফ-হোস্ট করা যায়।

ClickHouse-এ একটা কাঁচা টেবিল আর একটা দৈনিক rollup:

CREATE TABLE playback_events (
  ts           DateTime64(3),
  tenant       LowCardinality(String),
  asset        String,
  sid          String,
  viewer       String,
  event        LowCardinality(String),
  position_ms  UInt32,
  played_ms    UInt32,
  autoplay     Bool,
  country      LowCardinality(String),
  device       LowCardinality(String)
) ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (tenant, asset, ts)
TTL toDateTime(ts) + INTERVAL 13 MONTH;

-- per asset per day: views, watch time, completions
SELECT
  asset,
  toDate(ts)                                         AS day,
  uniqExactIf(sid, event = 'start' AND NOT autoplay) AS views,
  sum(played_ms) / 3600000                           AS watch_hours,
  uniqExactIf(sid, event = 'ended')                  AS completions
FROM playback_events
WHERE tenant = 'tnt_baytalhikma' AND ts >= now() - INTERVAL 30 DAY
GROUP BY asset, day
ORDER BY day DESC, watch_hours DESC;

ORDER BY (tenant, asset, ts) মানে একজন ক্রেতার একটা ভিডিওর ডেটা ডিস্কে পাশাপাশি থাকে, তাই প্রতি-ক্রেতা ড্যাশবোর্ড পুরো টেবিল না পড়েই চলে। মাল্টি-টেন্যান্ট সিস্টেমে প্রতিটা কুয়েরিতে tenant ফিল্টার বাধ্যতামূলক, আর ক্রেতার জন্য খোলা কুয়েরি এন্ডপয়েন্টে সার্ভার নিজে সেটা বসায়, ক্রেতার পাঠানো প্যারামিটার থেকে নয়।

এনগেজমেন্ট কার্ভ

একটা ভিডিওর প্রতিটা সেকেন্ডে কত শতাংশ দর্শক তখনও দেখছিল, সেটাই এনগেজমেন্ট কার্ভ। হার্টবিটের পজিশন দশ সেকেন্ডের বালতিতে ফেলে:

SELECT
  intDiv(position_ms, 10000) * 10 AS second,
  uniqExact(sid) / any(total)     AS still_watching
FROM playback_events
CROSS JOIN (SELECT uniqExact(sid) AS total FROM playback_events
            WHERE asset = 'ast_8Hn2c' AND event = 'start') AS t
WHERE asset = 'ast_8Hn2c' AND event = 'heartbeat'
GROUP BY second
ORDER BY second;

কার্ভ পড়তে শিখুন:

• প্রথম ৫-১০ সেকেন্ডে খাড়া পতন — থাম্বনেইল বা টাইটেল যা কথা দিয়েছিল, শুরুটা তা দিচ্ছে না; অথবা স্টার্টআপ টাইম বেশি। QoE ডেটার সাথে মেলান: যেসব সেশনে স্টার্টআপ তিন সেকেন্ডের বেশি, তাদের পতন কি বেশি?
• মাঝখানে হঠাৎ খাদ — ওই জায়গায় কিছু আছে: বিরক্তিকর অংশ, অডিও সমস্যা, বা একটা ভাঙা সেগমেন্ট যেখানে প্লেয়ার এরর দেয়।
• কার্ভে হঠাৎ উঁচু চূড়া — মানুষ পেছনে টেনে আবার দেখছে; ওটা সবচেয়ে মূল্যবান অংশ।
• শেষের আগে পতন — ক্রেডিট বা সারাংশ শুরু; এজন্যই কমপ্লিশন ৯০%-এ ধরা হয়।

QoE আর বিজনেসকে জোড়া লাগানো

ওয়াচ টাইম একা বলে না কেন কমল। sid দিয়ে QoE ইভেন্টের সাথে join করলে প্রশ্নগুলোর উত্তর মেলে: “রিবাফার রেশিও ১% এর বেশি যেসব সেশনে, তাদের গড় ওয়াচ টাইম কত?” “একটা নির্দিষ্ট ISP-এর দর্শক কি কম দেখছে?” এই জোড়াটাই ইঞ্জিনিয়ারিং বিনিয়োগকে টাকার ভাষায় দাঁড় করায়: “স্টার্টআপ এক সেকেন্ড কমালে ওয়াচ টাইম X% বাড়ে” একটা যুক্তি যা সবাই বোঝে।

খরচের মডেল

এবার খাতার দ্বিতীয় পাতা। একটা VOD প্ল্যাটফর্মের খরচ চারটা ভাগে, আর প্রতিটা ভিন্ন জিনিসের সাথে বাড়ে:

১. এনকোডিং — একবার, আপলোডের সময়। মোটামুটি:

encode_cost ≈ source_minutes × Σ over renditions (cpu_minutes_per_output_minute[r]) × cost_per_cpu_minute

cpu_minutes_per_output_minute কোডেক, প্রিসেট আর রেজোলিউশনের উপর নির্ভর করে, আর বিশাল পার্থক্য: একই রেজোলিউশনে AV1 বা ধীর x264 প্রিসেট দ্রুত প্রিসেটের চেয়ে বহুগুণ CPU খায়। নিজের হার্ডওয়্যারে একটা প্রতিনিধিত্বমূলক ক্লিপ দিয়ে মাপুন; অনুমান করবেন না (ট্রান্সকোডিং পাইপলাইন)।

২. স্টোরেজ — প্রতি মাসে, দেখা হোক না হোক:

storage_gb = source_gb + Σ renditions (bitrate_kbps[r] × duration_s / 8 / 1e6) × packaging_variants

packaging_variants হলো কতগুলো আলাদা কপি রাখছেন: HLS TS আর DASH আলাদা, বা এনক্রিপ্টেড আর আনএনক্রিপ্টেড আলাদা হলে গুণ হয়। CMAF আর just-in-time প্যাকেজিং এটাকে ১-এ নামায় (প্যাকেজিং কৌশল)। সোর্স ফাইল রাখবেন কিনা আলাদা সিদ্ধান্ত: রাখলে ভবিষ্যতে নতুন কোডেকে আবার এনকোড করা যায়, কিন্তু সোর্স প্রায়ই সব রেন্ডিশনের যোগফলের চেয়ে বড়।

৩. ডেলিভারি ইগ্রেস — প্রতিটা ভিউতে, আর প্রায় সবসময় সবচেয়ে বড়:

egress_gb ≈ Σ views × avg_watch_seconds × avg_delivered_bitrate_kbps / 8 / 1e6

খেয়াল করুন: এখানে রেন্ডিশনের সর্বোচ্চ বিটরেট নয়, গড় ডেলিভার হওয়া বিটরেট। ABR প্লেয়ার দর্শকের নেটওয়ার্ক অনুযায়ী বেছে নেয়, তাই এই সংখ্যা আসে CDN লগ বা প্লেয়ার ইভেন্ট থেকে, ল্যাডার থেকে নয়।

৪. অরিজিন ইগ্রেস ও রিকোয়েস্ট — প্রতিটা ক্যাশ MISS-এ অরিজিন থেকে CDN-এ ডেটা যায়, আর object storage প্রায়ই প্রতি রিকোয়েস্টেও চার্জ করে। এটা নির্ভর করে CDN অফলোড রেশিও-র উপর:

origin_egress_gb = egress_gb × (1 − byte_hit_ratio)

Origin shield এই রেশিও অনেক বাড়ায় (অরিজিন আর্কিটেকচার)। লম্বা লেজের লাইব্রেরিতে (হাজার হাজার ভিডিও, প্রতিটা কম দেখা) hit ratio স্বভাবতই কম, তাই এই খরচটা সেখানে চোখে পড়ার মতো হয়।

একটা হিসাব (illustrative)

একটা কোর্স প্ল্যাটফর্ম, মাসে:

INPUTS (illustrative)
  new uploads            200 hours of source
  ladder                 1080p 4.8 Mbps, 720p 2.6, 480p 1.2, 360p 0.7   (sum 9.3 Mbps)
  library                3,000 hours total, kept as CMAF (1 packaging variant), sources kept
  views                  400,000 / month, avg 9 min watched, avg delivered 1.8 Mbps
  byte hit ratio         0.95

DERIVED
  encode   200 h × 4 renditions                         -> measure CPU-min on your boxes
  storage  renditions: 3,000 h × 3600 s × 9.3 Mbps / 8  ≈ 12.6 TB
           sources (assume ~8 Mbps mezzanine)            ≈ 10.8 TB
  egress   400,000 × 540 s × 1.8 Mbps / 8               ≈ 48.6 TB
  origin   48.6 TB × (1 − 0.95)                         ≈ 2.4 TB

অনুপাতটাই শিক্ষা: মাসে প্রায় পঞ্চাশ টেরাবাইট ইগ্রেস বনাম প্রায় তেইশ টেরাবাইট স্টোরেজ, আর প্রতি গিগাবাইটে ইগ্রেস সাধারণত স্টোরেজের চেয়ে দামি। দর্শক বাড়লে ইগ্রেস রৈখিকভাবে বাড়ে, স্টোরেজ বাড়ে শুধু আপলোডে। তাই খরচ কমানোর প্রথম লিভার প্রায় সবসময় ডেলিভারিতে।

খরচ কমানোর লিভার

ক্রম অনুযায়ী, সাধারণত সবচেয়ে বেশি প্রভাব থেকে কম:

লিভার	কী করে	দাম
Per-title এনকোডিং	সহজ কনটেন্টে (স্লাইড, স্ক্রিন রেকর্ডিং) কম বিটরেটে একই কোয়ালিটি; ইগ্রেস আর স্টোরেজ দুটোই কমে	বাড়তি এনালাইসিস পাস (bitrate ladder)
ল্যাডার ছাঁটা	যে রেন্ডিশন প্রায় কেউ পায় না (মোবাইল-প্রধান দর্শকে 1080p) বাদ বা শুধু জনপ্রিয় ভিডিওতে	কিছু দর্শকের সর্বোচ্চ কোয়ালিটি কমে
ভারী ভিডিওতে নতুন কোডেক	সবচেয়ে বেশি দেখা ১-৫% ভিডিওতে HEVC বা AV1 রেন্ডিশন যোগ; একই কোয়ালিটিতে কম বাইট	বেশি এনকোডিং CPU, আর ডিভাইস সাপোর্টের জন্য H.264 রাখতেই হয়
Origin shield ও ক্যাশ নিয়ম	byte hit ratio বাড়ায়, অরিজিন ইগ্রেস আর রিকোয়েস্ট কমে	প্রায় শূন্য
Just-in-time প্যাকেজিং	একটা CMAF কপি থেকে HLS আর DASH; স্টোরেজ ভ্যারিয়েন্ট ১-এ	প্যাকেজার চালানো, প্রথম রিকোয়েস্টে লেটেন্সি
কোল্ড টায়ার	যে ভিডিও মাসের পর মাস কেউ দেখে না তার রেন্ডিশন সস্তা স্টোরেজ ক্লাসে	কোল্ড টায়ার থেকে পড়ায় দেরি আর রিট্রিভাল চার্জ হতে পারে
না-দেখা আউটপুট মোছা	কখনো না-দেখা ভিডিওর উচ্চ রেন্ডিশন মুছে দিয়ে চাহিদা এলে আবার এনকোড (সোর্স থাকলে)	প্রথম দর্শকের জন্য অপেক্ষা; সোর্স রাখতে হয়
লেজি এনকোডিং	আপলোডে শুধু ছোট ল্যাডার, পূর্ণ ল্যাডার প্রথম ভিউয়ের পর	নতুন ভিডিওর শুরুর দর্শক কম কোয়ালিটি পায়

কোডেক নিয়ে একটা কথা: নতুন কোডেক যোগ করা মানে পুরনোটা সরানো নয়। H.264 রেন্ডিশন সব ডিভাইসের জন্য থেকেই যায়, তাই নতুন কোডেক স্টোরেজ আর এনকোডিং বাড়ায়, আর লাভ আসে শুধু যেসব ভিউ নতুন কোডেক পায় তাদের ইগ্রেসে। তাই এটা শুধু সবচেয়ে বেশি দেখা ভিডিওতে লাভজনক, যেখানে এক ভিডিওর ইগ্রেস তার এনকোডিং খরচকে বহুগুণ ছাড়িয়ে যায়।

নিজের ক্রেতাকে স্বচ্ছ দাম

আপনি নিজে যদি অন্যদের কাছে VOD বিক্রি করেন, খরচের মডেলটাই প্রাইসিং মডেলের ভিত্তি। সৎ প্রাইসিংয়ের নিয়ম:

• ক্রেতা যা নিয়ন্ত্রণ করতে পারে, তা দিয়েই চার্জ করুন। এনকোডেড মিনিট, স্টোর করা মিনিট, ডেলিভার করা মিনিট (বা GB)। তিনটা আলাদা লাইনে, যেন ক্রেতা বোঝে কোনটা কমালে বিল কমবে।
• “ভিউ” দিয়ে চার্জ করলে সংজ্ঞা প্রকাশ করুন। উপরের সংজ্ঞার টেবিলের মতো, আর ক্রেতার ড্যাশবোর্ডে ঠিক যা দিয়ে বিল হয় সেটাই দেখান।
• সীমা পার হওয়ার আগে জানান। মাসের বাজেটের ৮০%-এ ইমেইল, আর ক্রেতা চাইলে হার্ড লিমিট সেট করতে পারবে যেখানে বিল আর বাড়বে না। অপ্রত্যাশিত বিল ক্রেতা হারানোর সবচেয়ে নিশ্চিত পথ।
• লুকানো ফি নেই। “প্ল্যাটফর্ম ফি”, “সাপোর্ট ফি” যা সাইনআপের পর দেখা দেয়, এগুলো ডার্ক প্যাটার্ন। দামের পাতায় যা আছে, বিলে তাই।
• বিলের লাইন আইটেম থেকে ড্রিল-ডাউন। কোন asset সবচেয়ে বেশি ইগ্রেস খেয়েছে, ক্রেতা নিজে দেখতে পারবে।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ	নিশ্চিত করুন	সমাধান
ক্রেতার নিজের অ্যানালিটিক্স আর আপনার ভিউ সংখ্যা মেলে না	দুই পক্ষের সংজ্ঞা পাশাপাশি লিখুন; অটোপ্লে আর ৩০-সেকেন্ড শর্ত	প্রকাশিত সংজ্ঞায় একমত হোন; ড্যাশবোর্ডে কোয়ালিফায়েড আর মোট দুটোই দেখান
ওয়াচ টাইম ভিডিওর দৈর্ঘ্য × ভিউয়ের চেয়ে বেশি	played_ms প্রতি সেশনে যোগ করে দেখুন; ডুপ্লিকেট হার্টবিট আছে কিনা	প্লেয়ার রিট্রাইতে একই হার্টবিট আবার পাঠাচ্ছে; ইভেন্টে সিকোয়েন্স নম্বর দিয়ে ডিডুপ
ওয়াচ টাইম হঠাৎ অর্ধেক, ভিউ একই	প্লেয়ার ভার্সন অনুযায়ী হার্টবিট সংখ্যা ভাগ করুন	নতুন প্লেয়ার রিলিজে হার্টবিট বন্ধ বা ইন্টারভাল বদলেছে; ইভেন্ট কন্ট্র্যাক্ট টেস্ট রাখুন
মোবাইলে ended ইভেন্ট প্রায় আসেই না	অ্যাপ ব্যাকগ্রাউন্ডে গেলে শেষ ইভেন্ট হারায় কিনা	কমপ্লিশন ended দিয়ে নয়, শেষ হার্টবিটের পজিশন ≥ ৯০% দিয়ে গুনুন; sendBeacon জাতীয় ফ্লাশ
ইগ্রেস বিল হিসাবের চেয়ে অনেক বেশি	CDN লগে গড় ডেলিভার্ড বিটরেট আর ভিউ-প্রতি বাইট	প্লেয়ার অতিরিক্ত বাফার করছে বা ছেড়ে দেওয়া ভিউয়েও সর্বোচ্চ রেন্ডিশন টানছে; বাফার টার্গেট দেখুন
অরিজিন ইগ্রেস বেশি, CDN hit ratio কম	byte hit ratio লেজের ভিডিও আর জনপ্রিয় ভিডিওতে আলাদা করে	origin shield চালু, ক্যাশ কী থেকে টোকেন বাদ (ক্যাশ কী)
স্টোরেজ লাইব্রেরির তুলনায় বেশি	প্রতি asset-এ কতগুলো প্যাকেজিং ভ্যারিয়েন্ট আর পুরনো ভার্সন আছে	ভ্যারিয়েন্ট এক CMAF-এ আনুন; রি-এনকোডের পর পুরনো আউটপুট মুছছে কিনা দেখুন
ড্যাশবোর্ড কুয়েরি ধীর	কুয়েরি প্ল্যানে কতটা ডেটা পড়ছে (EXPLAIN বা ClickHouse-এর read_rows)	ORDER BY-তে tenant আর asset আগে; দৈনিক rollup টেবিল বা materialized view

মূল শিক্ষা

1. সংজ্ঞা আগে, সংখ্যা পরে। ভিউ, কোয়ালিফায়েড ভিউ, ওয়াচ টাইম আর কমপ্লিশন লিখে প্রকাশ করুন; বিল আর ড্যাশবোর্ড একই সংজ্ঞায়।
2. ভিউ আসে প্লেয়ার ইভেন্ট থেকে, CDN লগ থেকে নয়, কারণ ডাউনলোড মানে দেখা নয়।
3. অ্যানালিটিক্স নিজের সার্ভারে, অস্বচ্ছ আইডিতে, IP থেকে শুধু দেশ, নির্দিষ্ট রিটেনশন।
4. শুরুতে PostgreSQL rollup, বড় হলে ClickHouse, ORDER BY-তে টেন্যান্ট প্রথমে।
5. এনগেজমেন্ট কার্ভ পড়ুন আর QoE-র সাথে sid দিয়ে জোড়া লাগান; ওটাই ইঞ্জিনিয়ারিং কাজকে টাকার ভাষা দেয়।
6. খরচ চার ভাগে: এনকোডিং একবার, স্টোরেজ প্রতি মাসে, ইগ্রেস প্রতি ভিউতে, অরিজিন প্রতি MISS-এ। ইগ্রেস সাধারণত সবচেয়ে বড়।
7. ইগ্রেস হিসাব করুন গড় ডেলিভার্ড বিটরেট দিয়ে, ল্যাডারের সর্বোচ্চ দিয়ে নয়।
8. প্রথম লিভার per-title আর ল্যাডার ছাঁটা, তারপর ক্যাশ, তারপর জনপ্রিয় ভিডিওতে নতুন কোডেক।
9. নিজের মেশিনে মাপুন, দাম প্রোভাইডারের পাতা থেকে নিন; অনুমানে খরচের মডেল বানাবেন না।
10. ক্রেতার কাছে প্রাইসিং স্বচ্ছ রাখুন: আলাদা লাইন আইটেম, সীমার আগে সতর্কতা, হার্ড লিমিট, কোনো লুকানো ফি নয়।