ANNOUNCING: Attendance and Attendance Taking

[Doug Tangren]

We've received an overwhelming amount of interest on the subject of organizer functionality being made available in the API. Today we are announcing the roll out of a few new features which should help you build the apps organizers with thank you for.

* Attendance and attendance taking.

Organizers of groups have access to a special tool on the website that allows them to track who attended and who was absent for a given event. This is useful for tracking who actually shows up over time.

Today you can do this through the API with

http://www.meetup.com/meetup_api/docs/:urlname/events/:id/attendance/#list

http://www.meetup.com/meetup_api/docs/:urlname/events/:id/attendance/#edit

With these new methods you should be able to do just about everything you can on the site. Note, these methods use the newer v3 response format which you can find out more about here - http://www.meetup.com/meetup_api/#v3_json

Editing the attendance of RSVP'd members changes the total number of what you see on the site for past events. In the API, we refer to this as the "headcount" of a given event. You can also get access to this per-event by requesting it in the "fields" parameter of any v2 event method - http://www.meetup.com/meetup_api/docs/2/events/#response

So how can you tell if you, the authenticated user, can actually take attendance for an event? You can get a list of actions you can perform on an event with the optional self field (http://api.meetup.com/2/event?event_id=123&fields=self) If you have proper permission to do so in the group, you will see "attendance" in that list.

As always, we welcome your feedback an interest in these new features.

Doug Tangren
Meetup
API Team

[jo...@lippeatt.com]

Doug,

Thanks very much for this.  Been looking forward to it!  The number of options this opens up for us is pretty significant.  Automatic "Why weren't you there?" emails when marking a no-show being among the first automation that's going to make my life much easier.

Couple of feedback items:

a) relying on urlname rather than group id ... can this be made either-or?  Member and Events are still identified as numeric, and some of us are retrieving group data based on its ID

b) your description mentions being able to track who showed up over time; but #lists is based on a single event.  Is it possible to use it for a user's aggregate activity data for all events?  (for example, for :id, use the identifier /all/)?  When we release someone, we include an email that says "You no-showed for the following 5 events in the past 6 months:"  it would be a HUGE timesaver if we could automate that (without iterating through all 156 of our events).

c) Some of us have more than 99 people attend events.  :)  (which is why we have been looking forward to a way to automate event attendance!!)

THANKS, huge help, very much appreciated.

Joe

--
You received this message because you are subscribed to the Google
Groups "Meetup API" group.
To unsubscribe from this group, send email to
meetup-api+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/meetup-api?hl=en?hl=en

[*Dominique*]

Yes thanks for this Doug as it is a big feature in my implementation as well. I have begun integrating it. I have noticed though that the addition of "created" and "updated" fields (as I see on most of your other data results) would greatly increase the efficiency of processing this data on my end as I could skip things that haven't changed since the last time I checked.

Dominique

[Doug Tangren]

On Thu, Nov 29, 2012 at 7:35 PM, jo...@lippeatt.com <jo...@lippeatt.com> wrote:

Doug,

Thanks very much for this.  Been looking forward to it!  The number of options this opens up for us is pretty significant.  Automatic "Why weren't you there?" emails when marking a no-show being among the first automation that's going to make my life much easier.

Couple of feedback items:

a) relying on urlname rather than group id ... can this be made either-or?  Member and Events are still identified as numeric, and some of us are retrieving group data based on its ID

This is a fair point. We went back and forth on this in the design going forward for these newer v3 methods. One of things that a bit annoying in the v2 (and v1) methods is if your starting point is your group or a group you know of you are much more likely to know the urlname off the top of your head. It's much more discoverable as well on the site. In that same respect we are trying to structure newer api urls in a similar way you'd access the the information on the site. The drawback (as you mentioned below) is that limits the number of groups you can query for in one request. On the plus side this url structure greatly simplifies filtering information some users should see and some should not but cause all data is related to on group. We don't have any plans to base the urls on group_ids yet. One thing I can do to help with the issue is to return group_urlname along side where you see group_id returned in responses.

 

b) your description mentions being able to track who showed up over time; but #lists is based on a single event.  Is it possible to use it for a user's aggregate activity data for all events?  (for example, for :id, use the identifier /all/)?  When we release someone, we include an email that says "You no-showed for the following 5 events in the past 6 months:"  it would be a HUGE timesaver if we could automate that (without iterating through all 156 of our events).

I actually like your idea for /all as an alias for all events over some required interval of time. This would probably need some other limiting factor (like a member_id) otherwise that may be a bit of an expensive on demand query. I'll open a ticket for looking into this.

 

c) Some of us have more than 99 people attend events.  :)  (which is why we have been looking forward to a way to automate event attendance!!)

That's what we like to hear. Keep the feedback coming. Going forward out main goal in the API is to make things easier and more useful for you developers to help build better tools for our members. You are our innovators.

[Doug Tangren]

On Thu, Nov 29, 2012 at 11:17 PM, *Dominique* <salt...@gmail.com> wrote:

Yes thanks for this Doug as it is a big feature in my implementation as well. I have begun integrating it. I have noticed though that the addition of "created" and "updated" fields (as I see on most of your other data results) would greatly increase the efficiency of processing this data on my end as I could skip things that haven't changed since the last time I checked.

Thanks for making a note of that. I'm not sure it would work in this case because in some cases we are not dealing with actually attendance database records, specifically for those that were absent and had no rsvp. This listing is manually an org controlled thing. Other users shouldn't be able to change it.

[jo...@lippeatt.com]

On Thu, Nov 29, 2012 at 10:47 PM, Doug Tangren <do...@meetup.com> wrote:
> On Thu, Nov 29, 2012 at 7:35 PM, jo...@lippeatt.com <jo...@lippeatt.com>
> wrote:
>>
>> a) relying on urlname rather than group id ... can this be made either-or?
>> Member and Events are still identified as numeric, and some of us are
>> retrieving group data based on its ID
>>
>
> This is a fair point. We went back and forth on this in the design going
> forward for these newer v3 methods. One of things that a bit annoying in the
> v2 (and v1) methods is if your starting point is your group or a group you
> know of you are much more likely to know the urlname off the top of your
> head. It's much more discoverable as well on the site. In that same respect
> we are trying to structure newer api urls in a similar way you'd access the
> the information on the site.

Not sure I can get on board with that. Although the custom urls are
very helpful when using the site, users aren't going to see the
data-access uri that's imbedded in my app.

Further, even if its to make it easier for *me* to read as a
developer, I'm only going to see the urls the first time I create the
string. So I might have to copy/paste an id once or twice, but once
the data retrieval code is complete, the rest is glue.

>> b) your description mentions being able to track who showed up over time;
>> but #lists is based on a single event. Is it possible to use it for a
>> user's aggregate activity data for all events? (for example, for :id, use
>> the identifier /all/)? When we release someone, we include an email that
>> says "You no-showed for the following 5 events in the past 6 months:" it
>> would be a HUGE timesaver if we could automate that (without iterating
>> through all 156 of our events).
>>
>
> I actually like your idea for /all as an alias for all events over some
> required interval of time. This would probably need some other limiting
> factor (like a member_id) otherwise that may be a bit of an expensive on
> demand query. I'll open a ticket for looking into this.

Agreed, it would be specifically to retrieve the activity of a single
user in a specific group.

>> c) Some of us have more than 99 people attend events. :) (which is why
>> we have been looking forward to a way to automate event attendance!!)
>
> That's what we like to hear. Keep the feedback coming. Going forward out
> main goal in the API is to make things easier and more useful for you
> developers to help build better tools for our members. You are our
> innovators.

So the "99 attendees" limitation can be removed, possibly?

Thanks!

[Doug Tangren]

That 99 is guests per member (http://www.meetup.com/meetup_api/docs/:urlname/events/:id/attendance/#editparams) This is a limit that should be enforced on the site as well. 

[jo...@lippeatt.com]

So the "99 attendees" limitation can be removed, possibly?

That 99 is guests per member (http://www.meetup.com/meetup_api/docs/:urlname/events/:id/attendance/#editparams) This is a limit that should be enforced on the site as well.

OH, totally misread that.  Thanks.