Solved

Revenue-per-Recipient or Revenue-per-Delievery? The way to calculate RPR seems not the same as the document statement..

  • 13 December 2022
  • 5 replies
  • 242 views
X
Rank
Badge +1

Hello,

 

When I was looking at the dashboard data（Home->Performance）, I found that the calculation of the flow’s $/Recipient(RPR) indicator seemed to be different from what was stated in this document. In the documentation, the numerator is GMV and the denominator is uniq emails. But I observed from the actual data that the denominator of the calculation presented in the dashboard is the total number of emails delievery, not uniq emails. I just want to check whether my observation is right.

 

Below is my calculation process.

Step1, I select the date range between 20221206 and 20221213 (last 7DAYS). And then, I select a flow, which revenue(gmv) is $11059 and $/recipient is $3.92.

 

Step2, In such date range, I click such flow and check the detail data. This flow has three scene, I record each scene’s GMV and email delievery count

1）scene1, gmv 10374.31, email delievery 921

2）scene2, gmv 215.31, email delievery 909

3）scene3, gmv 469.02, email delievery 993

 

4）after record the data, I do the calculation

sum_gmv = 10374.31 + 215.31 + 469.02 = 11058.64

sum_email_delievery = 921 + 909 + 993 = 2823

sum_gmv / sum_email_delievery = 11058.64 / 2823 = 3.91733

 

step3, data check

in dashboard, the gmv is 11059 and $/recipient is 3.92, shown in pic1.

in flow detail, the gmv is 11058.64(round to 11059) and gmv/delievery=3.91733(round to 3.92)

it seems $/recipient is the same as $/delievery. In my opinion, recipient is uniq-delievery-emails, not sum-delievery-emails, like the document statemented.

 

I just want to check whether my observation is right, and why the difference happen between dashboard data and document.

icon

Best answer by David To 13 December 2022, 16:57

View original

5 replies

David To
Rank
Userlevel 7
Badge +60

Hello @xuyang,

Welcome to the Klaviyo Community!

I think you’re making a distinction when there isn’t one. To calculate revenue per recipient you’ll want to divide the revenue attributed to a campaign or flow by the number of recipients in that campaign or flow. Similarly, if you were calculating the revenue per recipient for multiple emails, the calculation would simply be the total revenue attributed to all of those campaigns or flows divided by the total number of recipients in those campaigns or flows. 

I believe the confusion here lies in your opinion of “recipient is unique-delievery-emails, not sum-delievery-emails”. When we talk about the total unique delivered emails and the total sum of delivered emails, they’re the same thing. Another way to think about it is asking yourself what does a “unique” delivery look like? Since emails are delivered one time to a recipient, there wouldn’t be a distinction between unique and sum. Even if someone were to re-enter a flow, that would count as another unique delivery to that recipient - hence a sum of two delivered emails. 

Overall, it doesn’t seem like there is any discrepancy between how our dashboard is calculating the revenue per recipient compared to what we have documented in our How to Use Revenue per Recipient Benchmarks to Plan Sales Performance Help Center article.

Thanks for being a part of the Community!

David

X
Rank
Badge +1

Hi @David To ,

 

Thanks for you reply, and  Klaviyo Community is really a kind place to communicate with each other.

 

As of now, I think we have understood each other's perception of "recipient" well enough. Yes, you are right, in my  opinion, “recipient is unique-delievery-emails, not sum-delievery-emails”. Because I think recipients represent customers, one customer own one email in common. In other words, I think the essence of  revenue per recipient  indicator is ARPU, that is, how much revenue a customer can bring to the business. If the recipient and deliever are same, is there any indicator similar to ARPU in klaviyo.

 

In addition, I recently discovered some data mismatch problems, if I have any questions later, may I directly @ you in post?

 

 

David To
Rank
Userlevel 7
Badge +60

Hey @xuyang,

In your context, I think both ARPU (average revenue per user) and RPR (revenue per recipient) are the same thing. 

The only other context I see with ARPU is if you were looking at the average revenue per user for your entire account. In which case it would still be considered revenue per recipient, but at a much larger scale. 

Since the Community forum is a space for Klaviyo Customers, partners and other users to network and learn from one another, if you’ve noticed any data mismatches in your account, I would encourage you to reach out to our wonderful Support colleagues. 

David

P
Rank
Badge +1

I’m not familiar with a lot of these terms but I do understand the Revenue per recipient metric now… but I’d be more interested in knowing what the monthly revenue per email contact is and how it matches with the industry (is this even a “thing”?)… I suppose this is LTV?); is there a “revenue number” for each contact on my list? Or is this the same metric that we’ve been discussing in this forum? 

David To
Rank
Userlevel 7
Badge +60

Hey @Paul do Campo,

Just for some clarification, monthly revenue per email contact is not the same as LTV (lifetime value). LTV or CLV (customer lifetime value) as it’s considered in Klaviyo, is the total revenue a customer has spent. 

I believe CLV can be considered the “revenue number” for each contact on your list that you were interested in. 

Although similar, CLV is not the same thing as revenue per recipient. CLV isn’t determined based on the revenue source, but rather the total sum of revenue value a customer has brought in. Whereas revenue per recipient is tied specifically to attributed revenue- hence the “per recipient” aspect. 

David

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Links & Resources

Platforms

Partners

Useful Things

About

  • Terms and Privacy
    © 2024 Klaviyo All rights reserved. Klaviyo and the Klaviyo logo are trademarks or registered trademarks of Klaviyo, Inc. or its affiliates.