Body: <p>I've just been responding to a client's query about why the numbers in the membership dashboard (/civicrm/member?reset=1) don't tally up.</p>
  <p>I assume, although it's not clear, that the data displayed in the dashboard should show the number of new membership sign-ups and the number of renewing memberships, broken down across the last month, the current month, and the year to date, itemised by membership type.</p>
  <p>What we've seen on this particular site (currently a little behind the curve on CiviCRM 5.25.0 so forgive me if the issue set our here has already been addressed and I'm not yet aware of that) is that the figures given for the 'Renew' columns are not always correct.</p>
  <p>I looked at a specific example for a membership type where the dashboard was reporting 20 New and 3 Renew membership for the month to date, and then giving a total of 22. Overall on this site we've got a mismatch along these lines of 25 for the YTD numbers (551 New, 68 Renew, 601 Total) which is really unhelpful.</p>
  <p>I looked into the details to see where these numbers might be coming from. I ran a search to find all contacts where the target membership type had been initiated and where the 'Member Since' date was in the current month, working on the assumption that this would give me list of contacts who had signed up in this month for the specific membership type. Hey presto, I get 20 results. So far so good.</p>
  <p>So how can I find the reported 3 renewals? Doing an Advanced Search for contacts with the relevant membership type and a Membership Start Date in the current month, which I would assume would give me at least the three renewals I was looking for), turned up just one result.</p>
  <p>So I then ran a further Advanced Search to find contacts who had the membership, where the membership status was 'Current' (thereby ruling out new sign-ups which would have a status of 'New'), and where a contribution had been made in the current month (memberships are paid).</p>
  <p>This second search turned up 2 results, so at least we now have a match on the numbers reported (although of course no guarantee that these three contacts are the same three that are being reported in the Dashboard (as that offers no drill down).</p>
  <p>Looking at the three contact records in detail I could see that in two cases they had upgraded to the target membership from a different membership type, and that this had happened in the current month. Whilst this isn't strictly speaking a renewal of the target membership type I can understand why it would be considered as such in a high level overview such as that which the Dashboard seeks to provide.</p>
  <p>The third record showed that the membership type had been acquired two months ago, upgrading a previous membership of a different type, and that the contact had since made a further contribution unrelated to membership in the current month. So this record should not have been included in the current month's figures at all.</p>
  <p>Of course all I've got to go on, as I'm not sufficiently skilled to delve into the code to find out how the Renew numbers are calculated, is the fact that my efforts to understand what might be going on threw up a plausible analysis that matched the numbers being reported.</p>
  <p>I would be interested to learn of others' experiences of using/understanding this dashboard, and whether this issue, which in our experience is generating misleading information for users, constitutes a bug.</p>
  <p>For now I've advised my client to totally ignore the 'Renew' numbers and I've suggested that if they want to get some useful reporting on what's happening with memberships, then other routes (e.g. Drupal Views, other Civi reporting tons), may well be the way to go. Of course that would likely involve them in additional work, when - given that membership management is a core pillar of the feature set of CiviCRM - it seems reasonable to expect that this sort of stuff should be available and accurate, off the shelf.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-12T18:23:43.727Z
Comments.Text: Have you taken into account the number of members in 'Grace' status, which you don't mention.  That affects the numbers.
Comments.UserDisplayName: Andy Clark
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-14T11:05:51.237Z
Comments.Text: I'm not clear what you mean Andy? As far as I can see the numbers should show the number fo sign-ups and the number ofd renewal in the period. What role does Grace status play here?
Comments.UserDisplayName: Graham
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-14T11:10:30.913Z
Comments.Text: None of those columns mention those members in 'grace', so I wonder if they are included or not, as they would affect the numbers.
Comments.UserDisplayName: Andy Clark
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-14T11:20:59.123Z
Comments.Text: I don't see how they would affect the numbers?
Comments.UserDisplayName: Graham
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-14T11:24:32.913Z
Comments.Text: I can see that if grace memberships are included they should be counted in the 'Current #' column, but not anywhere else in that Dashboard display.
Comments.UserDisplayName: Graham
Tags: <civimember><reports><dashboard>
Title: How does CiviCRM work out the numbers it reports in the 'Renew' columns on the Membership Dashboard?
ThreadText: # How does CiviCRM work out the numbers it reports in the 'Renew' columns on the Membership Dashboard?
  
  (Asked by: username_0 on 2021-03-12)
  
  I've just been responding to a client's query about why the numbers in the membership dashboard (/civicrm/member?reset=1) don't tally up.
  
  I assume, although it's not clear, that the data displayed in the dashboard should show the number of new membership sign-ups and the number of renewing memberships, broken down across the last month, the current month, and the year to date, itemised by membership type.
  
  What we've seen on this particular site (currently a little behind the curve on CiviCRM 5.25.0 so forgive me if the issue set our here has already been addressed and I'm not yet aware of that) is that the figures given for the 'Renew' columns are not always correct.
  
  I looked at a specific example for a membership type where the dashboard was reporting 20 New and 3 Renew membership for the month to date, and then giving a total of 22. Overall on this site we've got a mismatch along these lines of 25 for the YTD numbers (551 New, 68 Renew, 601 Total) which is really unhelpful.
  
  I looked into the details to see where these numbers might be coming from. I ran a search to find all contacts where the target membership type had been initiated and where the 'Member Since' date was in the current month, working on the assumption that this would give me list of contacts who had signed up in this month for the specific membership type. Hey presto, I get 20 results. So far so good.
  
  So how can I find the reported 3 renewals? Doing an Advanced Search for contacts with the relevant membership type and a Membership Start Date in the current month, which I would assume would give me at least the three renewals I was looking for), turned up just one result.
  
  So I then ran a further Advanced Search to find contacts who had the membership, where the membership status was 'Current' (thereby ruling out new sign-ups which would have a status of 'New'), and where a contribution had been made in the current month (memberships are paid).
  
  This second search turned up 2 results, so at least we now have a match on the numbers reported (although of course no guarantee that these three contacts are the same three that are being reported in the Dashboard (as that offers no drill down).
  
  Looking at the three contact records in detail I could see that in two cases they had upgraded to the target membership from a different membership type, and that this had happened in the current month. Whilst this isn't strictly speaking a renewal of the target membership type I can understand why it would be considered as such in a high level overview such as that which the Dashboard seeks to provide.
  
  The third record showed that the membership type had been acquired two months ago, upgrading a previous membership of a different type, and that the contact had since made a further contribution unrelated to membership in the current month. So this record should not have been included in the current month's figures at all.
  
  Of course all I've got to go on, as I'm not sufficiently skilled to delve into the code to find out how the Renew numbers are calculated, is the fact that my efforts to understand what might be going on threw up a plausible analysis that matched the numbers being reported.
  
  I would be interested to learn of others' experiences of using/understanding this dashboard, and whether this issue, which in our experience is generating misleading information for users, constitutes a bug.
  
  For now I've advised my client to totally ignore the 'Renew' numbers and I've suggested that if they want to get some useful reporting on what's happening with memberships, then other routes (e.g. Drupal Views, other Civi reporting tons), may well be the way to go. Of course that would likely involve them in additional work, when - given that membership management is a core pillar of the feature set of CiviCRM - it seems reasonable to expect that this sort of stuff should be available and accurate, off the shelf.
  
  **Tags:** civimember, reports, dashboard
  
  > **Comments:**
  > **username_1**: Have you taken into account the number of members in 'Grace' status, which you don't mention.  That affects the numbers.  
  > **username_0**: I'm not clear what you mean Andy? As far as I can see the numbers should show the number fo sign-ups and the number ofd renewal in the period. What role does Grace status play here?  
  > **username_1**: None of those columns mention those members in 'grace', so I wonder if they are included or not, as they would affect the numbers.  
  > **username_0**: I don't see how they would affect the numbers?  
  > **username_0**: I can see that if grace memberships are included they should be counted in the 'Current #' column, but not anywhere else in that Dashboard display.  
  
  ---
  
  ## 0 answers
  
  