Custom user fields are a very commonly-used feature in ActionKit. Many clients use them to store information like a user’s employer or occupation, but there are SO many different bits of information that could be useful to store!
In this blog post, we’ll give you a few ideas of things you can do with custom user fields, but what you do with it is completely up to you!
Why should I use custom user fields?
Beyond storing useful data like a user’s employer or occupation, lots of clients like to run reports on historical data, like “how much money did this user given in 2020?” “How much did they give in 2018? 2016?”
Unless someone has a time machine, historical data like that doesn’t change very often. The amount someone gave in 2016 is fixed. But calculating that information from the database — depending on what data you’re retrieving, how far back you’re going, how many users you have, and a few other factors — this can be VERY slow!
Lots of clients also like to us merge queries to calculate suggested ask snippets based on historical donation data including a user’s highest previous contributions, but there are so many ways to calculate suggested asks!
Still, if you’re often using merge queries in your mailings, and you find those merge queries are very slow, you might want to use custom user fields to make your mailings build much more quickly.
Some common reasons your reports, mailing builds, and merge queries might be slow include:
- Your report / merge query looks at large database tables including millions or hundreds of millions of entries
- Your report / merge query could benefit from caching or optimization
- Your report / merge query performs time-consuming calculations on several years of historical data
And when you’re targeting your mailings to hundreds of thousands or millions of people, and doing these calculations each time for every single recipient, that can slow things down even further.
Don’t forget summary_user
For many common situations, we already have fields that you can use — you don’t need to create a custom user field to calculate information like:
- When did a user last take action?
- When did a user last take action from a mailing?
- When did a user last receive a mailing?
- When did a user last open a mailing?
- When did a user last click a mailing?
- When did a user last donate?
- When was a user last subscribed to the main email list?
- How many actions did a user take in the last 30 days? 60? 90? 180? 270? 365?
For these questions, see the summary_user table, where we’ve collected these stats and keep them updated.
One way to think about custom user fields is as a supplement to summary_user!
Why this matters
Using custom user fields, your mailing builds will complete MUCH more quickly than if you were doing these queries on the fly.
You can also use custom user fields as snippets available in your pages and your mailings.
Don’t forget — you can target your mailings based on your custom user field data.
Some example ideas
Here are a few example ideas for custom user fields that you could do:
- Count of donations made in 2020
- Amount of donations made in 2020
- Largest one-time donation ever made
- Amount a user can give before they “max out” (for political parties and candidates)
- Propensity scores
How to get started
You can of course have your users enter data into custom user fields on forms like surveys and petitions. But to add data in bulk, read on.
First, create a custom user field that will store the information you want to capture. In this example, we’ll use a field called donation_count_2020 to store the number of donations a user made in calendar year 2020.
Next, create a report that calculates the value of what that custom user field should be for each user.
Notice that the name of the column where we’re calculating the number of donations a user made in 2020 is “user_donation_count_2020” — this is important, as it must match the name of the custom user field we created above, with the “user_” prefix.
The first column here is the user ID, which will be important later when we upload the file.
Then, run your report and view the results. When the results look correct to you, download it as a CSV (comma separated values) file.
Next, create an import page. (As a general rule, when importing custom user fields, I’d make sure the import page was set to not change the subscription status of the users you upload)
Next, upload your file, being sure to check the box that says “Skip Action Creation”. This will make your upload go much faster — though it only works when you’re only uploading custom user fields, which we are here.
When the upload completes, all of the users you imported will have the number of donations they made in 2020 stored in the custom user field donations_count_2020!
Although it may seem strange to upload data from ActionKit back into ActionKit, this is a great way to set up custom user fields — and best of all, take advantage of big speed improvements by not needing to calculate the values every time.
But how do I keep user data up to date?
You’re probably thinking “This is nice, but it’ll never work for us, because I’m not doing a manual import every day to keep this information up to date!”
And you shouldn’t have to! That’s time-consuming, easy to forget or miss, and error-prone. Much better to do it automatically!
This is where user updaters come in. User updaters are a new feature that’s specifically designed to help you keep your custom user fields up to date on a regular schedule. You’ll make a report similar to the one we made above, then set it to run on a schedule. We’ll update your users’ custom fields on a regular basis and you don’t have to think about it ever again!
Give this a try — and be sure and let us know via support how you’re using custom user fields! We love to know all of the creative ways that you’re using ActionKit.
Also be sure to check out a video version of this blog post, plus our feature spotlight blog posts and videos on summary_user and user updaters for more!
Interested in scheduling a demo with ActionKit? Let us know!