Is there any way to identify all Teamraiser donors?

Jeffrey Kaplan

We are trying to segment out Peer to Peer (Teamraiser) donors from a welcome series, but are unable to find any way to identify said donors in a dynamic/future-proof fashion. Since these donors have donated on behalf of someone else who raised awareness of the organization, we see them as a second group that should be treated uniquely in messaging until they have taken further action with the organization. However we are having trouble identifying them across the board.

 

We've looked at the following three tools but none seem feasible: Tasks, Queries, and Campaign Groups

 

Tasks: There is a "Teamraiser Participant" task that allows you to create a group of all teamraiser participants, but I am unable to find an equivalent tool for identifying "Teamraiser Donors".

 

Queries: Each teamraiser event does have a donors group automatically created, but when you have 100+ events each year, you are unable to add all of these groups to a query (it maxes out the query tool), despite which you would have to update the query every time a new event is created.

 

Campaign Group: Our other option is to use the donation campaign feature of "Campaign Group" to add all donors to a specific campaign to a specific group, but this feels very unstable because it requires that we set every campaign that is taking teamraiser donations to add users to the same group, which not only ties up that campaign group field from any other use, but also requires us to continually add it to any future teamraiser donation campaigns.

 

Is there any way to segment all Teamraiser donors into a group?

 

Thanks,

Jeffrey

Chris Backus

Try creating a rebuildable group based on this query:

 

have interaction type 'Contact Record Change' with subject: 'TeamRaiser'

 

Jeffrey Kaplan

Chris Backus:

Try creating a rebuildable group based on this query:

 

have interaction type 'Contact Record Change' with subject: 'TeamRaiser'

 

This is a good trick -- it certainly gets close. Only issues with this method are:

 

- It includes registered TR participants (who may or may not have not donated) in the results, as registering for a teamraiser event prompts the same "Contact Record Change" interaction with subject "TeamRaiser". So the results are still not exclusively donors. You can exclude anyone who has participated in a TeamRaiser event from the results (by using a task-generated teamraiser participants group), but this runs on a delay and you would also exclude teamraiser participants who HAVE donated.

 

- It doesn't include offline donors -- the contact record update interaction is not always triggered for offline donation entries.

 

 

Thanks for the suggestion Chris!

Brian Mucha

Jeffrey Kaplan:

This is a good trick -- it certainly gets close. Only issues with this method are:

 

- It includes registered TR participants (who may or may not have not donated) in the results, as registering for a teamraiser event prompts the same "Contact Record Change" interaction with subject "TeamRaiser". So the results are still not exclusively donors. You can exclude anyone who has participated in a TeamRaiser event from the results (by using a task-generated teamraiser participants group), but this runs on a delay and you would also exclude teamraiser participants who HAVE donated.

 

- It doesn't include offline donors -- the contact record update interaction is not always triggered for offline donation entries.

 

 

Thanks for the suggestion Chris!

Also, you really what to retreive those that originated as TR donors.

 

I could have registered for your newsletter, poked around, found out about your TR and donated. I think I should get the regular WS, not the peer-to-peer WS.

 

 

Chris Backus

Jeffrey Kaplan:

This is a good trick -- it certainly gets close. Only issues with this method are:

 

- It includes registered TR participants (who may or may not have not donated) in the results, as registering for a teamraiser event prompts the same "Contact Record Change" interaction with subject "TeamRaiser". So the results are still not exclusively donors. You can exclude anyone who has participated in a TeamRaiser event from the results (by using a task-generated teamraiser participants group), but this runs on a delay and you would also exclude teamraiser participants who HAVE donated.

 

- It doesn't include offline donors -- the contact record update interaction is not always triggered for offline donation entries.

 

 

Thanks for the suggestion Chris!

I checked a few records and I'm seeing that registering for a TR actually prompts the interaction type "TeamRaiser Registration" with the subject being that TR event's name.  As far as I can tell they're only getting the "Contact Record Change" with the subject of "TeamRaiser" if they donate.

 

(If it does include them, though, you could suppress the TR participants group as you mentioned, then use a second query to add participants who have donated to the same "TR Donors" group, using using AND instead of NOT.)

 

Good point about the offline donors, but would there be many people who give offline that already have constituent records with email addresses that wouldn't have already been through your welcome series?

Jeffrey Kaplan

Brian Mucha:

Also, you really what to retreive those that originated as TR donors.

 

I could have registered for your newsletter, poked around, found out about your TR and donated. I think I should get the regular WS, not the peer-to-peer WS.

 

 

@Brian:

 

I agree that welcome series should be based on the origin of the record, though in this case we have separate messaging that we dont want people to see if they've taken certain actions such as Peer to Peer donating. So we are prioritizing [the status of the record at the time of the message send] over [the origin of the record] -- with the idea being users can switch between welcome series message tracks by having taken different actions since the previous message (so we dont continue to prompt them to donate if they did end up donating, etc).

 

That being said, there is a query filter for [System > Origin Application Type > Teamraiser Donor], but it has returned no results in every convio instance i've checked it in, so I don't think this is being captured.

 

 

Brian Mucha

Chris Backus:

I checked a few records and I'm seeing that registering for a TR actually prompts the interaction type "TeamRaiser Registration" with the subject being that TR event's name.  As far as I can tell they're only getting the "Contact Record Change" with the subject of "TeamRaiser" if they donate.

 

(If it does include them, though, you could suppress the TR participants group as you mentioned, then use a second query to add participants who have donated to the same "TR Donors" group, using using AND instead of NOT.)

 

Good point about the offline donors, but would there be many people who give offline that already have constituent records with email addresses that wouldn't have already been through your welcome series?

I tried the query and the first result I looked at did not have any TR donations, it was just a TR Registration.

Brian Mucha

Jeffrey Kaplan:

@Brian:

 

I agree that welcome series should be based on the origin of the record, though in this case we have separate messaging that we dont want people to see if they've taken certain actions such as Peer to Peer donating. So we are prioritizing [the status of the record at the time of the message send] over [the origin of the record] -- with the idea being users can switch between welcome series message tracks by having taken different actions since the previous message (so we dont continue to prompt them to donate if they did end up donating, etc).

 

That being said, there is a query filter for [System > Origin Application Type > Teamraiser Donor], but it has returned no results in every convio instance i've checked it in, so I don't think this is being captured.

 

 

System > Origin Application Type > Teamraiser Donor = Empty results for me too.

 

That reliability requirement a tough hump to get over if Convio doesn't have a special trick. Everything I can think of requires some type of set up.

 

How about a custom boolean and a profile setting field on the donation form which you could query against. (IsPeerDonor = TRUE)

 

Or you can configure donation tiers to add the user to a group. Just set every tier on your form to add the donor to the Peer Donors group. Better than your original Campaign group, cause for us the registration and DSP forms are also in the same campaign. Same issues with future set up tho.

Jeffrey Kaplan

Chris Backus:

I checked a few records and I'm seeing that registering for a TR actually prompts the interaction type "TeamRaiser Registration" with the subject being that TR event's name.  As far as I can tell they're only getting the "Contact Record Change" with the subject of "TeamRaiser" if they donate.

 

(If it does include them, though, you could suppress the TR participants group as you mentioned, then use a second query to add participants who have donated to the same "TR Donors" group, using using AND instead of NOT.)

 

Good point about the offline donors, but would there be many people who give offline that already have constituent records with email addresses that wouldn't have already been through your welcome series?

@Chris:

 

The teamraiser registration can prompt the "Contact Record Change" interaction if the record existed before it was registered for the event and the system sees any disparity between the submitted information and the previously stored information.

 

Sometimes even an empty field on both ends can trigger it -- if the "Street" field was empty on the cons record and empty in the registration form, the system treats the new submission as "none" and the old submission as "empty" and considers it a change to the record. Other changes I'm seeing happen a lot can be email_opt_out_nonce, which is a field that gets updated with a new key anytime a user opts-in to accept email, email status from "Unknown" to "Good" (based on autoresponder going through), or "Active Detail" on the record being changed.

 

Again, this gets *really* close to doing it, and the number of records that actually qualify for these exceptions is probably pretty small...

Jeffrey Kaplan

Chris Backus:

Try creating a rebuildable group based on this query:

 

have interaction type 'Contact Record Change' with subject: 'TeamRaiser'

 

For posterity's sake:

 

We ended up using the following query:

 

 

have interaction type 'Contact Record Change' with subject: 'TeamRaiser'
AND have no interaction of type 'TeamRaiser Registration' 

 

It uses the "Contact Record Change" interaction provided by Chris and additionaly filters out all constituents who had registered for any teamraiser event. This worked for our purposes because we wanted to filter out all teamraiser participants anyways. But note that this group is not all P2P donors, but rather all P2P donors who have not registered for any Teamraiser event themselves.