วิธีแปลงไฟล์ส่งออกข้อมูลการสมัครสมาชิกให้เป็นรายงาน MRR และ ARR (คู่มือปี 2026)

ไฟล์ส่งออกข้อมูลการสมัครสมาชิกจะแสดงข้อมูลเป็นแถว ได้แก่ ลูกค้า, แผนบริการ, ยอดเงิน, ช่วงเวลา, สถานะ และวันที่เริ่มต้น ส่วนรายงาน MRR ต้องการตัวเลขเพียงตัวเดียวต่อเดือน การแปลงข้อมูลจากรูปแบบหนึ่งไปเป็นอีกรูปแบบหนึ่งดูเหมือนจะเป็นเรื่องของคณิตศาสตร์ แต่จริงๆ แล้วส่วนใหญ่เป็นเรื่องของการกำหนดนิยาม

มีการตัดสินใจสองข้อที่จะกำหนดตัวเลขทุกตัวในรายงานฉบับสมบูรณ์ นั่นคือ การสมัครสมาชิกใดบ้างที่ถือว่ามีผลใช้งานอยู่ (active) และจะหักส่วนลดออกจากยอดเงินหรือไม่

หากตัดสินใจผิดพลาดไปอย่างใดอย่างหนึ่ง รายงานก็ยังคงมียอดที่ดุลกันภายในตัวมันเอง เพียงแต่มันจะไม่ตรงกับข้อมูลของฝ่ายการเงิน แดชบอร์ดระบบเรียกเก็บเงิน และรายงานของเดือนที่แล้วเท่านั้นเอง

คู่มือนี้จะครอบคลุมถึงสิ่งที่คุณต้องจัดการเป็นอันดับแรก วิธีการทำด้วยตนเอง 3 วิธี และจุดที่แต่ละวิธีเริ่มใช้ไม่ได้ผล

สิ่งที่คุณต้องเตรียมก่อนเริ่มต้น

คุณต้องใช้ไฟล์ส่งออกที่มีข้อมูลหนึ่งแถวต่อหนึ่งการสมัครสมาชิก ไม่ใช่หนึ่งแถวต่อหนึ่งใบแจ้งหนี้ เพราะใบแจ้งหนี้จะบอกว่ามีการเรียกเก็บเงินอะไรไปบ้าง แต่การสมัครสมาชิกจะบอกว่ามีรายการใดบ้างที่เกิดขึ้นซ้ำ

คุณต้องมีคอลัมน์ช่วงเวลาการเรียกเก็บเงิน (billing interval) ในทุกแถว แผนบริการแบบรายเดือนและรายปีจะไม่สามารถนำมารวมกันได้จนกว่าจะแปลงแผนบริการรายปีให้เป็นค่ามาตรฐาน (normalised) เสียก่อน

นอกจากนี้ คุณยังต้องมีคอลัมน์สถานะ (status) ด้วย เอกสารวิเคราะห์การเรียกเก็บเงินของ Stripe นิยาม MRR ว่าเป็นผลรวมของยอดเงินที่แปลงเป็นรายเดือนตามมาตรฐานแล้ว โดยจะนับเฉพาะการสมัครสมาชิกที่มีสถานะ active และ past_due เท่านั้น

นิยามดังกล่าวเป็นสิ่งที่ควรนำมาใช้โดยไม่ต้องแก้ไข เนื่องจากมีการเผยแพร่อย่างเป็นทางการ มีความเฉพาะเจาะจง และช่วยให้คุณมีคำตอบที่อธิบายได้เมื่อมีคนถามว่าทำไมตัวเลขถึงเปลี่ยนไป

และนี่คือ 3 การตัดสินใจที่คุณต้องทำเป็นอันดับแรก

สถานะใดบ้างที่ถูกนับ สถานะ Active รวมกับ past due คือค่าเริ่มต้นตามที่ระบุไว้ในเอกสาร ส่วนสถานะ Canceled และ unpaid จะถูกปฏิบัติเสมือนเป็นลูกค้าที่ยกเลิกบริการ (churn) และจะถูกตัดออกไป

จะหักส่วนลดออกหรือไม่ Stripe อนุญาตให้ตั้งค่าส่วนนี้ได้ โดยมีการตั้งค่าแยกกันสำหรับส่วนลดแบบเกิดซ้ำและส่วนลดแบบครั้งเดียว ส่วนลดแบบตลอดชีพ (forever discounts) จะถูกหักออกเสมอ

จะเริ่มนับผู้สมัครใช้งานเมื่อใด Stripe ให้คุณเลือกได้ว่าจะเริ่มนับตั้งแต่จุดเริ่มต้นของรอบการเรียกเก็บเงินรอบแรก หรือเมื่อได้รับชำระเงินครั้งแรก ซึ่งตัวเลือกแรกเป็นตัวเลือกที่นิยมใช้กันมากที่สุด

เขียนการตัดสินใจทั้งสามข้อนี้ลงในชีตก่อนที่คุณจะเริ่มเขียนสูตร เพราะสิ่งเหล่านี้คือเส้นแบ่งระหว่างรายงานที่ถูกต้องกับการโต้เถียงที่ไม่มีวันจบ

ทำไมเรื่องคณิตศาสตร์ถึงเป็นส่วนที่ง่ายที่สุด

การแปลงค่าให้เป็นมาตรฐานนั้นง่ายมาก ตัวอย่างการคำนวณของ Stripe เองใช้ผู้สมัครใช้งาน 100 รายในแผนบริการรายเดือนราคา $100 บวกกับอีก 50 รายในแผนบริการรายปีราคา $600 ซึ่งจะได้ผลลัพธ์เป็น (100 × 100) + (50 × (600 / 12)) = 12,500

ความซับซ้อนที่แท้จริงอยู่ที่รายการยกเว้นต่างๆ ซึ่งเป็นเรื่องที่มองข้ามได้ง่ายมากในสเปรดชีต

ไม่รวมภาษี Stripe จะไม่รวมภาษีใน MRR หากไฟล์ส่งออกของคุณเป็นยอดเงินรวมภาษี (gross amount) แสดงว่าคุณกำลังประเมินตัวเลขสูงเกินจริงในทุกๆ เดือน

ไม่รวมช่วงทดลองใช้งาน การสมัครสมาชิกที่อยู่ในช่วงทดลองใช้งาน (trial period) จะถูกยกเว้นจนกว่าจะเปลี่ยนเป็นผู้ใช้งานจริงที่ชำระเงิน

ไม่รวมแผนบริการฟรี ผู้สมัครใช้งานในแผนบริการราคาศูนย์บาทไม่ได้สร้างรายได้ใดๆ ดังนั้นจึงไม่ถูกนับเป็นผู้สมัครใช้งานที่มีผลใช้งานอยู่ (active subscriber) เช่นกัน

ไม่รวมรายได้ตามการใช้งานจริง (usage-based) นี่คือจุดที่ทำให้หลายคนประหลาดยใจ ผลิตภัณฑ์ที่คิดเงินตามปริมาณการใช้งาน (metered products) จะถูกคัดออกจาก MRR ทั้งหมด ดังนั้น ธุรกิจที่มีการเรียกเก็บเงินตามการใช้งานบางส่วนจะเห็นตัวเลข MRR ต่ำกว่ารายได้จริง ซึ่งเป็นเรื่องปกติที่ถูกออกแบบมาเช่นนั้นอยู่แล้ว

นอกจากนี้ยังมีกรณีของคูปอง ซึ่งมีการระบุไว้ในเอกสารและเป็นเรื่องที่ขัดกับความรู้สึกอย่างแท้จริง หาก MRR ของผู้สมัครใช้งานลดลงเหลือศูนย์ ผู้สมัครใช้งานรายนั้นจะถูกปฏิบัติเสมือนว่ายกเลิกบริการ (churned) ในช่วงเวลาดังกล่าว

คูปองส่วนลด 100% จะส่งผลเช่นนั้นพอดี และหากคุณนำคูปองออกในภายหลัง ผู้สมัครใช้งานรายนั้นก็จะกลับมามีสถานะใช้งานอยู่ (active) อีกครั้ง ซึ่งจะแสดงในรายงานเป็นการกลับมาใช้งานใหม่ (reactivation)

ดังนั้น การจัดโปรโมชันอาจทำให้เกิดตัวเลขการยกเลิกบริการ (churn) ในรายงานของคุณได้ ทั้งที่ไม่มีลูกค้าจากไปเลยแม้แต่รายเดียว

วิธีการทำด้วยตนเอง

ทางเลือกที่ 1: แปลงช่วงเวลาให้เป็นมาตรฐาน แล้วรวมยอดตามเดือน

เพิ่มคอลัมน์ยอดเงินรายเดือน โดยหารยอดเงินรายปีด้วย 12 คูณยอดเงินรายสัปดาห์ด้วยประมาณ 4.33 และปล่อยยอดเงินรายเดือนไว้ตามเดิม

จากนั้นรวมยอดตามเดือนด้วยสูตร SUMIFS โดยกรองตามสถานะ และใช้สูตร EOMONTH เพื่อสร้างวันที่สิ้นสุดของเดือนที่คุณต้องการรายงานผล

รายงาน MRR ณ วันสิ้นเดือน ไม่ใช่ ณ วันปัจจุบัน รายงานที่ดาวน์โหลดได้ของ Stripe จะระบุ MRR ของผู้สมัครใช้งานแต่ละราย ณ วันสิ้นเดือนอย่างชัดเจน และการปฏิบัติตามแนวทางนี้จะช่วยประหยัดเวลาในการกระทบยอด (reconciliation) ในภายหลัง

ข้อจำกัดของวิธีนี้คือข้อมูลย้อนหลัง วิธีนี้จะช่วยให้คุณได้ข้อมูลของเดือนปัจจุบันอย่างชัดเจน แต่จะไม่บอกอะไรเลยเกี่ยวกับสาเหตุที่ตัวเลขนั้นเปลี่ยนแปลงไป

ทางเลือกที่ 2: สร้างคอลัมน์แสดงการเคลื่อนไหวของข้อมูล

นี่คือสิ่งที่จะทำให้รายงานมีประโยชน์อย่างแท้จริง โดยการจำแนกการเปลี่ยนแปลงออกเป็น: ลูกค้าใหม่ (new), การกลับมาใช้งานใหม่ (reactivation), การอัปเกรดแพ็กเกจ (expansion), การดาวน์เกรดแพ็กเกจ (contraction) และการยกเลิกบริการ (churn)

นิยามการเติบโตของ Stripe คือ ตัวเลขเริ่มต้น บวกด้วยลูกค้าใหม่ การกลับมาใช้งานใหม่ และการอัปเกรดแพ็กเกจ หักออกด้วยการดาวน์เกรดแพ็กเกจและการยกเลิกบริการ จากนั้นปรับปรุงด้วยอัตราแลกเปลี่ยน ตัวอย่างการคำนวณของ Stripe แสดงให้เห็นว่าตัวเลขเปลี่ยนจาก $1,000 เป็น $1,045 ผ่านองค์ประกอบเหล่านี้อย่างชัดเจน

โปรดสังเกตปัจจัยสุดท้าย หากมีลูกค้าชำระเงินในสกุลเงินอื่น โมเดลที่ใช้สูตรคำนวณเพียงอย่างเดียวจะไม่สามารถกระทบยอดได้จนกว่าคุณจะจัดการกับผลกระทบจากอัตราแลกเปลี่ยน

การรองรับหลายสกุลเงินยังมีผลกระทบประการที่สองที่ควรรู้ Stripe ระบุว่าการกรองและการจัดกลุ่มตามผลิตภัณฑ์หรือราคาจะไม่สามารถใช้งานได้เมื่อรายได้จากการสมัครสมาชิกถูกจัดการในหลายสกุลเงิน

ข้อจำกัดของแนวทางนี้คือการดูแลรักษาข้อมูล คอลัมน์แสดงการเคลื่อนไหวจำเป็นต้องใช้ข้อมูลภาพรวม (snapshot) ของรอบระยะเวลาก่อนหน้า ซึ่งหมายความว่าคุณต้องเก็บสำเนาข้อมูลของเดือนที่แล้วไว้อีกชุดหนึ่งตลอดไป

ทางเลือกที่ 3: ดึงข้อมูลการเคลื่อนไหวจากระบบเรียกเก็บเงินโดยตรง

แพลตฟอร์มเรียกเก็บเงินส่วนใหญ่จะส่งออกข้อมูลการเคลื่อนไหวให้คุณ โดย Stripe จะเผยแพร่ไฟล์ CSV สามไฟล์ ได้แก่ MRR ต่อผู้สมัครใช้งานรายเดือน, สรุปตัวชี้วัดการสมัครสมาชิก และบันทึกประวัติการเคลื่อนไหวของ MRR ของลูกค้าแต่ละราย

ไฟล์ที่สามคือไฟล์ที่คุณควรเรียกใช้ เพราะมันจะช่วยตัดส่วนที่ยากที่สุดของทางเลือกที่ 2 ออกไป

หากคุณเปลี่ยนนิยามของตัวชี้วัด โปรดเผื่อเวลาไว้ด้วย เนื่องจาก Stripe ระบุว่าการเปลี่ยนแปลงการตั้งค่าอาจใช้เวลา 24 ถึง 48 ชั่วโมงจึงจะแสดงผล

ข้อจำกัดร่วมกัน ทั้งสามแนวทางนี้สิ้นสุดลงที่ MRR เท่านั้น การจะแปลงข้อมูลให้เป็น ARR, ARPU, อัตราการยกเลิกบริการ (churn) และอัตราการรักษาลูกค้า (retention) หมายถึงคุณต้องตัดสินใจเพิ่มขึ้นอีกระดับหนึ่งบนตารางข้อมูลเดิม

จุดที่การทำด้วยตนเองเริ่มช้าลง

ในเดือนแรกอาจใช้เวลาเพียงช่วงบ่ายวันเดียว แต่ในเดือนที่สี่จะใช้เวลานานขึ้น และไม่ใช่เพราะข้อมูลมีความซับซ้อนมากขึ้นแต่อย่างใด

เมื่อถึงตอนนั้น เวิร์กบุ๊กของคุณจะมีนิยามของสถานะ active ถึงสองแบบ มีคอลัมน์อัตราแลกเปลี่ยนที่ต้องแก้ไขด้วยมือ และแท็บแสดงการเคลื่อนไหวของข้อมูลที่ไม่มีใครอยากเข้าไปแตะต้อง

ตัวชี้วัดที่ดึงข้อมูลต่อเนื่องมาจะยิ่งเพิ่มปัญหาเป็นทวีคูณ ARPU คือ MRR ทั้งหมดหารด้วยจำนวนผู้สมัครใช้งานที่มีผลใช้งานอยู่ (active subscribers) ส่วนมูลค่าตลอดช่วงชีวิตของลูกค้า (Lifetime value) คือ ARPU หารด้วยอัตราการยกเลิกบริการ (churn rate)

อัตราการยกเลิกบริการ (churn) ก็มีกับดักของมันเอง ตัวหารของ Stripe คือจำนวนผู้สมัครใช้งานที่มีผลใช้งานอยู่เมื่อ 30 วันก่อน บวกกับผู้สมัครใช้งานใหม่ที่เพิ่มเข้ามาในช่วงเวลาดังกล่าว ซึ่งจะได้ผลลัพธ์เป็น 100 / (1000 + 100) = 9.1% แต่สเปรดชีตที่หารด้วยจำนวนเริ่มต้นเพียงอย่างเดียวจะรายงานตัวเลขที่สูงกว่า

อัตราการรักษาลูกค้า (retention) ก็แสดงผลลัพธ์ที่คาดไม่ถึงได้เช่นกัน อัตราการรักษาลูกค้าเชิงรายได้ (revenue retention) อาจสูงเกิน 100% ได้ เนื่องจากยอดการอัปเกรดแพ็กเกจ (expansion) ภายในกลุ่มผู้ใช้งานกลุ่มเดียวกัน (cohort) มีมูลค่ามากกว่ายอดการยกเลิกบริการ (churn)

ไม่มีขั้นตอนใดในนี้ที่ยากเลย มันเป็นเพียงการตัดสินใจ 5 ข้อที่ต้องทำเหมือนเดิมทุกประการในทุกๆ เดือน ไม่ว่าใครจะเป็นผู้สร้างรายงานนั้นก็ตาม

วิธีสร้างรายงานด้วย Powerdrill Bloom

ขั้นตอนที่ 1: อัปโหลดไฟล์ส่งออกข้อมูลการสมัครสมาชิกของคุณ

อัปโหลดไฟล์ CSV ของการสมัครสมาชิก หรืออัปโหลดไฟล์การสมัครสมาชิกและไฟล์การเคลื่อนไหวพร้อมกัน Powerdrill Bloom จะวิเคราะห์โครงสร้างคอลัมน์ทันทีที่ได้รับข้อมูล ดังนั้น ช่วงเวลาที่ขาดหายไป ยอดเงินที่ว่างเปล่า และ ID การสมัครสมาชิกที่ซ้ำกันจะถูกตรวจพบก่อนที่จะมีการคำนวณยอดรวมใดๆ

ขั้นตอนที่ 2: ระบุนิยามด้วยภาษาธรรมชาติ

อธิบายกฎเกณฑ์ต่างๆ แทนที่จะต้องสร้างมันขึ้นมา ระบุว่าสถานะใดบ้างที่ถูกนับ ยอดเงินเป็นยอดสุทธิหลังหักส่วนลดหรือไม่ และคุณกำลังรายงานผลของวันสิ้นเดือนใด

จากนั้นสั่งให้ตรวจสอบข้อมูลในคราวเดียวกัน ถามว่าแถวใดมีช่วงเวลาที่คุณไม่ได้คาดคิด และการสมัครสมาชิกใดมียอดเป็นศูนย์หลังหักส่วนลด แล้วถามว่ายอดรวมรายเดือนตรงกับข้อมูลสรุปการเรียกเก็บเงินหรือไม่

ขั้นตอนที่ 3: ส่งออกแผนภูมิ รายงาน หรือสไลด์นำเสนอ

ดึงข้อมูลแนวโน้มรายเดือน ตารางแสดงการเคลื่อนไหวแยกตามองค์ประกอบ หรือสไลด์ที่พร้อมนำเสนอต่อคณะกรรมการซึ่งมีทั้งตัวเลขและนิยามระบุไว้อย่างครบถ้วน

ทำไมวิธีนี้ถึงดีกว่าการสร้างรายงานใหม่ทุกเดือน

	วิธีการทำด้วยตนเอง	Powerdrill Bloom
การแปลงแผนบริการรายปีให้เป็นมาตรฐาน	ต้องสร้างคอลัมน์สูตรในทุกไฟล์	เพียงอัปโหลดและระบุกฎเกณฑ์
การจำแนกการเคลื่อนไหวของข้อมูล	ต้องคอยดูแลรักษาข้อมูลภาพรวมของเดือนก่อนหน้า	เพียงขอข้อมูลแยกตามองค์ประกอบ
การยกเว้นช่วงทดลองใช้งานและรายการตามการใช้งานจริง	ต้องกรองข้อมูลด้วยตนเองในทุกรอบ	เพียงระบุรายการที่ต้องการยกเว้น
การกระทบยอดกับข้อมูลสรุปการเรียกเก็บเงิน	ต้องตรวจสอบด้วยตนเอง	เพียงถามว่ายอดรวมตรงกันหรือไม่

แถวตรงกลางตารางคือส่วนที่ทำให้เสียเวลามากที่สุด การรวมยอดในคอลัมน์ไม่ใช่เรื่องยาก แต่การรักษานิยามทั้ง 5 ข้อให้คงที่ในแต่ละเดือนต่างหากที่เป็นงานหนัก

ข้อผิดพลาดที่พบบ่อย

การรวมยอดจากใบแจ้งหนี้แทนการสมัครสมาชิก ใบแจ้งหนี้จะรวมค่าบริการแบบจ่ายครั้งเดียวและการคิดเงินตามสัดส่วน (prorations) รายได้ที่เกิดขึ้นซ้ำ (recurring revenue) เป็นคุณสมบัติของการสมัครสมาชิก ไม่ใช่ของบิลเรียกเก็บเงิน

การปล่อยให้มีภาษีรวมอยู่ในยอดเงิน ภาษีจะทำให้ตัวเลขสูงเกินจริงในทุกๆ เดือนและไม่เคยหักล้างกันได้หมด ควรตัดภาษีออกก่อนที่จะแปลงค่าให้เป็นมาตรฐาน

การนับช่วงทดลองใช้งานเป็นรายได้ ช่วงทดลองใช้งานยังไม่มีการเกิดยอดเงินจริง การรวมยอดส่วนนี้เข้ามาเปรียบเสมือนการกู้ยืมการเติบโตของเดือนหน้ามาใช้ล่วงหน้า

การคิดว่า ARR คือ MRR คูณ 12 โดยไม่มีการระบุให้ชัดเจน ARR คือตัวเลขรายปีที่แปลงเป็นมาตรฐานแล้ว ไม่ใช่เงินสดที่เก็บได้จริง ควรติดป้ายกำกับให้ชัดเจนเพื่อไม่ให้ใครเข้าใจผิดว่าเป็นยอดจอง (bookings)

การละเลยผลกระทบจากคูปองต่อการยกเลิกบริการ (churn) ส่วนลดเต็มจำนวนจะทำให้ยอดของผู้สมัครใช้งานลดลงเหลือศูนย์ ซึ่งระบบจะอ่านค่าเป็นการยกเลิกบริการ ควรทำเครื่องหมายที่แถวเหล่านั้นไว้ ดีกว่าต้องมาคอยอธิบายในภายหลัง

การหารอัตราการยกเลิกบริการด้วยจำนวนเริ่มต้น ตัวหารตามที่ระบุในเอกสารจะรวมผู้สมัครใช้งานที่เพิ่มเข้ามาในช่วงเวลาดังกล่าวด้วย การคำนวณทั้งสองแบบนี้จะให้ผลลัพธ์ที่แตกต่างกันแม้จะใช้ข้อมูลชุดเดียวกันก็ตาม

การสร้างรายงานใหม่ทั้งหมดตั้งแต่ต้นในทุกๆ เดือน นิยามต่างๆ ไม่ได้เปลี่ยนไป มีเพียงไฟล์ส่งออกเท่านั้นที่เปลี่ยน ควรเก็บกฎเกณฑ์เดิมไว้แล้วใช้วิธีเปลี่ยนไฟล์ข้อมูลแทน ซึ่งเป็นหลักการเดียวกับการทำ รายงานเปรียบเทียบงบประมาณกับค่าใช้จ่ายจริง (budget versus actual report)

บทสรุป

กำหนดรายการสถานะให้ชัดเจน ตัดสินใจเรื่องส่วนลด แปลงช่วงเวลาให้เป็นมาตรฐาน และรายงานผล ณ วันสิ้นเดือน ขั้นตอนทั้ง 4 ข้อนี้จะช่วยสร้างรายงาน MRR ที่สามารถตอบข้อซักถามจากฝ่ายการเงินได้อย่างมั่นใจ

ส่วนที่ยากและเสียเวลาที่สุดไม่ใช่การรวมยอด แต่คือการที่นิยามทั้ง 5 ข้อต้องคงที่ในทุกๆ เดือน ในขณะที่ไฟล์ส่งออกเปลี่ยนรูปแบบไปเรื่อยๆ

หากนั่นคือสิ่งที่ทำให้คุณเสียเวลาในช่วงสิ้นเดือน ลองใช้ Powerdrill Bloom กับไฟล์ส่งออกข้อมูลการสมัครสมาชิกของคุณ และคุณยังสามารถดูคู่มือของเราเกี่ยวกับ การตั้งเป้าหมาย KPI จากข้อมูลของคุณเอง สำหรับข้อมูลด้านเครื่องมือ สามารถดูเพิ่มเติมได้ที่บทความรวบรวม เครื่องมือ AI สำหรับการติดตามตัวชี้วัด SaaS และหน้า การวิเคราะห์ทางการเงินด้วย AI (AI financial analysis)

คำถามที่พบบ่อย

สูตรคำนวณ MRR จากไฟล์ส่งออกข้อมูลการสมัครสมาชิกคืออะไร?

แปลงการสมัครสมาชิกทุกรายการให้เป็นยอดเงินรายเดือนตามมาตรฐาน จากนั้นรวมยอดเฉพาะรายการที่มีสถานะตรงตามเงื่อนไข ตัวอย่างของ Stripe คือ (100 × $100) + (50 × ($600 / 12)) = $12,500

ฉันจะแปลง MRR เป็น ARR ได้อย่างไร?

คูณตัวเลขรายเดือนด้วย 12 และระบุป้ายกำกับว่าเป็นอัตราการดำเนินงานรายปีที่แปลงเป็นมาตรฐานแล้ว (normalised annual run rate) ไม่ใช่เงินสดที่เก็บได้จริง เนื่องจากแผนบริการรายปีจะมีการเรียกเก็บเงินล่วงหน้า

ควรนำรายได้ตามการใช้งานจริง (usage-based revenue) มารวมด้วยหรือไม่?

Stripe จะไม่รวมผลิตภัณฑ์ที่คิดเงินตามปริมาณการใช้งาน (metered products) ใน MRR หากรายได้ส่วนสำคัญของคุณมาจากฐานการใช้งานจริง แนะนำให้รายงานแยกเป็นอีกบรรทัดหนึ่งแทนที่จะนำมารวมกัน

สถานะการสมัครสมาชิกใดบ้างที่ถือว่ามีผลใช้งานอยู่ (active)?

ค่าเริ่มต้นตามที่ระบุในเอกสารคือ active รวมกับ past_due ส่วนการสมัครสมาชิกที่มีสถานะ Canceled และ unpaid จะถูกปฏิบัติเสมือนเป็นการยกเลิกบริการ (churn) และจะถูกตัดออกจากยอดรวม

ทำไมอัตราการยกเลิกบริการ (churn rate) ของฉันถึงไม่ตรงกับแดชบอร์ดระบบเรียกเก็บเงิน?

สาเหตุส่วนใหญ่เกิดจากตัวหาร การคำนวณตามที่ระบุในเอกสารจะหารด้วยจำนวนผู้สมัครใช้งานที่มีผลใช้งานอยู่เมื่อ 30 วันก่อน บวกกับผู้สมัครใช้งานใหม่ที่เพิ่มเข้ามาในช่วงเวลาดังกล่าว