Add join_time and leave_time to past_meeting participation report

Feature Requests
1

This is for developer-specific feature requests. For other requests please contact our customer support team.

Is your feature request related to a problem? Please describe.
A current frustration for me and my target audience is that the meeting reports my users can generate through zoom.us are not available through the OAuth App we created to assist them with scheduling meetings. My audience is educators running online classes and break-out sessions, and they need to track student attendance and participation over the duration of the semester. (In the education space, attendance tracking is a vital function.) My goal is to help them collate individual per-meeting participant reports and transform them into per-participant attendance reports across a series of meetings. The join_time and leave_time are critical pieces of information for me when I do this.

Describe the solution you’d like

Ideally, I would like to see the same level of detail contained in the report/meetings/{meeting_id}/participants response (join_time, leave_time, etc.) in the past_meetings/{meetingUUID}/participants response.

If that recategorizes the rate limit on that existing call, I propose a companion “past meeting participation detail” report that takes the same parameters but provides the fuller set of fields, so as not to change the performance profile of the existing API call.

If that doesn’t work, I then propose that the meeting participation report to be recategorized under the meeting:read, or meeting:write scope, and employ the same business logic / security that, for example, doesn’t let my application use the OAuth token for one user to update another user’s meeting.

I realize the first two proposals would constitute the only heavy rate_limit call in the meeting API, so if that’s the insurmountable hurdle, perhaps it could be handled asynchronously like cloud recordings - with a ‘take attendance’ meeting-setting to generate a participant detail report (or not) at the conclusion of the meeting, and then a lightweight call to provide a URL to the generated report.

Describe alternatives you’ve considered
We’ve considered building a separate account-level OAuth App for reports, but that poses problems within the organization in that it’s an admin call, so would give me access to participation for everyone’s meetings at our large university (my app serves only a 20-50 users), which is less than ideal. Another disadvantage to this approach is that we would also have to maintain a separate OAuth token repository and connector keys, requiring refactoring our code base to parameterize the OAuth App. (Not a big deal in the long term, but a code complication.)

I’ve also considered creating a standalone service web-service app that our university’s Zoom application support team would maintain and apply business rules to mimic a user-level app and limit who’s meetings we could get reports on (with an account-level OAuth App built into it). That would provide them with control over both the call frequency, and scope. However, it requires them to maintain another service, and for us to periodically update the allowed-user list.

Both solutions above seem like workarounds that are likely to be high-maintenance and brittle over time as we attempt to recreate and augment Zoom’s security approach.

The “as-is” approach also considered would be to substitute the past_meeting participation report, but it does not give us enough information on how long each participant attended the meeting session, so that is deemed inadequate. (We are looking for total minutes within the scheduled meeting timeframe, to preclude counting as present a student who joins and leaves early.)

Additional context
The main constraint for my particular situation is that not all meetings for a class are owned by the same user, so that probably precludes a fully-automated attendance solution based on recurring meetings or user-id.

My development plan was to query for meeting participation reports by meeting_id, and store the reports in our database after first retrieval to avoid repeat API calls for the same meeting. I would develop the usual exponential back-off strategy for request re-tries. For the most part, I anticipate API calls to be triggered by a background job vs the known scheduled meetings, because, based on manual retrieval of participation reports through the zoom.us portal, it is a relatively time-consuming call and I can get better user-response time if I pre-fetch.

If potential resource starvation is the issue for you, I’m happy to discuss other limits or call-bundling that might conserve compute resources on your end, or other constraints that provide the right balance.

Hopefully this something you might consider. I think it would be valuable to the entire education-sector user base.

Regards,

Robert

2 Likes
2

I must say nice suggestion after visiting this.

3

I’m not a developer, although we do have one. I thank Robert for this well written post and second his request.

We are a non-profit producer of medical education and peer support for medical providers, paying Zoom over $7.5K per year for one monthly Webinar.

We need to report out on an entire year of attendees, what their demographics are, and for each webinar they attended. The current reporting UI limits this information to one month only. Additionally, there is no usable file record layout in the current CSV reporting file.

4

Thank you for sharing your concerns. We understand the importance of detailed reporting for medical education webinars. To address the current limitations in Zoom’s reporting UI, consider reaching out to their support team for insights or explore manual aggregation using CSV exports for now. If you have a developer, they can assist in streamlining this process and customizing the layout for your medical imaging-focused data.