Hello!

I have an idea that’s a bit on the technical side, if you’re open to it. 

So, first thing to keep in mind is that when a superadmin sets up a deeplink, anyone who clicks the deeplink, and is subsequently enrolled to the course, is considered “enrolled by” that superadmin. 

Within the Docebo API for retrieving enrollments (image attached), part of the response body includes “subscribed_by”, which is the user_id of the user who enrolled the user to the course. 

So, if you had a dedicated superadmin account just for creating deeplinks, you could call the enrollments API to understand which users were “subscribed_by” that particular admin, and that would give you your deeplink click count/rate. 

Again, slightly on the technical side as far as setup/implementation, but feasible!

Nate

hey Nate,

Thanks for the answer! The suggestion sounds like a pretty good workaround and it’s good to learn that it matters which superadmin creates deeplinks.

Unfortunately, since we have numerous superadmins and we’re using single sign-on, it’s pretty much impossible for us to logout, therefore, it would be even a bit more of a hassle than I would like. We could, however, think about having a dedicated superadmin (in person, not just an account) who doesn’t do any enrollments aside from generating deeplinks so it’s still useful! Thanks 

@natemadel that’s such a cool idea and a super clever way to report on this. I would have never thought of that 🧠 

@abartunek I’ve had great success in the past using custom redirects in Pardot (the marketing automation tool my previous organization used) to track clicks on specific course links. Most marketing automation tools have some sort of link-tracking ability (HubSpot, for example, has Tracking URLs). If your organization has a marketing automation tool, I recommend exploring that as an option! You could essentially create a library of these tracked links that you use for various enrollment links to capture individual clicks. We would often use multiple links for the same link in different locations. For example, we’d track clicks on our website’s homepage vs. our community homepage vs. our Docebo homepage.

@Adam Ballhaussen thanks for the recommendation! I will check Pardot out and also contact our marketing; perhaps we already have something that can be used in a similar way within the organisation and I’m just not aware.

Hello, I’ve been trying to replicate this solution but it looks like they changed the API and this information is not available anymore?

I would LOVE to know what has happened to this endpoint. I didn’t specifically recall that it previously existed – so thanks for flagging this evidence that it did, @giuseppe_eco – but I was certainly surprised to find recently that there was no way to retrieve a list of enrollments for a given user via the API.

I can only retrieve enrollment data by going through the course(s) first, and it’s incredibly inefficient to have to loop through every course to get the data I’m looking for for one user.

Edit: I just checked with a custom action to this endpoint in Docebo Connect, and it appears to still be functional (and the responses still include the subscribed_by field). So the question becomes, why is it no longer documented in the API Browser?!

@Ian even if you loop through each course, from what I can see there is no way of retrieving the ‘enrolled_by’ information - unless I’m missing something?

Oh, you replied quickly, @giuseppe_eco! I think you’re right that when looping through from the course side, the subscribed_by field is not included. But I’m hoping my edit to my previous post is helpful to you: turns out the endpoint still works.

One tip that may help: you need to pass the user and/or course IDs as arrays. I have, in the past, struggled with that, but I believe the way to do it is:

GET learn/v1/enrollments?id_useri]={user_id}&id_course_]={course_id}&with_visibility=both

Thanks, but this would still require to loop through every user id right? In our case, with hundred of thousands of users, that would be problematic...

Apologies, @giuseppe_eco, I was again too focused on my own use case. So, to me this is pretty counter-intuitive, but the answer appears to be simply to include the parameter more than once. Like this: 

GET learn/v1/enrollments?id_usere]={user_id_1}&id_usere]={user_id_2}&id_usere]={user_id_n}&id_courses]={course_id}&with_visibility=both

I imagine the same logic applies to the id_course parameter as well (which is optional anyway, I should add).

I don’t know what the limit is, in terms of how many IDs you can add at once. You’ll obviously need to handle some pagination in any case, so hopefully batching the user IDs is reasonable. For my part I’m wondering what other parameters might be available for filtering, so that you don’t have to fetch literally every enrollment each time you do this (if it’s going to be a regular thing, that is). For example, if you’d do this weekly. I wonder if you can sort the output by subscription date and then, while you’re paging through it, stop when you hit a date more than one week in the past?

Oops.

Would that I could delete community posts I’ve made that turned out to be completely wrong. Most of my “contributions” to this thread would fall under that umbrella. Here’s what I’ve learned from a Docebo Support conversation regarding the matter:

1. The GET learn/v1/enrollments endpoint has in fact been deprecated for 2½ years. This was announced in Product Updates way back in the May 11, 2021 Weekly Update. That’s why it’s no longer documented. It still works because it’s used internally for some reason, but if that would change, it’d be shut off without any further notice.
    
2. I had been under the impression that there was no substitute for what it offered, but I somehow missed the very existence of GET /course/v1/courses/enrollments (I had only found the similar-yet-very-different GET /course/v1/courses/{id}/enrollments, which did not help with my use case. This is not the first time I’ve missed an endpoint despite spending a lot of time looking for it, so I’ve now submitted this idea:

    

3. GET /course/v1/courses/enrollments does include the information as to who enrolled the end user, in the form of the enrollment_created_by field.
    
4. Also, it does support sorting by enrollment_created_at (in fact, that’s the default sort), so it would help with the last point in my previous post, @giuseppe_eco.