%203.png){kind=small}
ARI SUSSMAN JUL 16, 2023
A copy of article is pasted below:
Use cases for Jewish engagement data How operating organization use cases for engagement data is the linchpin to making the case for centralized data collection and analysis. ARI SUSSMAN JUL 16, 2023 Over the past year of connecting with a variety of people across multiple types of Jewish organizations I’ve been struck by the amount of times I’ve heard about the potential power behind organizations sharing data. The theory is that if we’re all in this together and genuinely want to see more engagement and meaning as a whole in our community, we should be tailoring our experiences and marketing to current and prospective customers in a more personalized way. The key to effective personalization is gaining a better understanding of our customers through data.
There is some merit to this general point of view. As Jewish activity has become disparate across a broader range of informal and formal institutions and the scale of interaction with single organizations has reduced, the bar has been raised on acquiring new customers to your Jewish product or service and then retaining them over time. As I described in this piece, consumers have both a higher bar for suitable experiences and they increasingly have less loyalty to single organizations, instead wanting to piece together their ideal Jewish journey. As a result it has become harder for conveners and operating organizations alike to piece together the longitudinal journeys of their constituents. It stands to reason that by creating more open access to data, and thus helping our organizations understand these journeys, we can create more traction overall
in our community.
The challenge is that these are all statements of theory. Once you start to really grapple with data sharing you run into issues with privacy, the perceived risk of bombarding constituents with communications, and how to make data actionable and understandable.
I would argue that any effort to centralize data collection should focus on actual use cases to try and uncover the real benefits associated with sharing data. If we can make the benefits of data sharing and warehousing more tangible for all of the constituents involved we may find a way to work through its challenges.
Use cases of a data sharing system
The goal of a communal Jewish interactions data warehouse is to collect as many consumer engagement and demographic data points as possible and turn that data into insights and actions that can help all parties achieve their respective goals. The question is what insights and actions actually look like.
Below, I’ve tried to capture both a longer term vision for each use case, but also a more pragmatic way we can start. With new product development I’ve found it is often useful to paint a longer term vision and then from there figure out how to dial that back into a nearer term outcome. This allows you to build excitement for the future and ensure that short term actions map to that aspirational long term state. I believe a similar approach could be warranted here. While we might start with a more pragmatic easier approach, if we better understand the future yield of these use cases we can better garner internal, philanthropic, and partner support.
Participant use cases: Central data collector
A central data collector could be a Federation or a third party that exists for the benefit of the community. This entity (or a third party it hires) would be responsible for building out the mechanisms to collect data and also be responsible for structuring that data in ways that benefit itself and its partners. Tactically, it would build interfaces, likely digital, to collect event and membership data from partner organizations and then turn that data around into interfaces that would allow for insight.
Central Collector use case 1:
Report on the participation characteristics and engagement health of the community
Federations struggle with cost effective mechanisms to study their populations. Many of them conduct community studies every 5-10 years that cost hundreds of thousands of dollars. They typically use third parties who design sophisticated sampling approaches to make sure they are surveying representative segments of the population. The output is a 50+ page report that analyzes the results.
There are two issues with this approach.
They are a one-size fits all document with limited ability to analyze the community in ways that resonate for specific constituents. If you want to cut the data in a way that isn’t included in the report you have to go back to the consulting firm that produced the report or be fluent in statistical analysis tools like Stata or SPSS to conduct any form of analysis.
They are very expensive and time intensive and thus are conducted infrequently which means Federations are frequently doubting their data arguing that things might have changed since the last survey.
Collecting “bottom up” participation data would allow for a data set that is constantly updating itself and whose results can be viewed in a more interactive manner. The results of such a system could be housed in a system that allows users to ‘drag and drop’ values and measures into charts. Below is an example of an illustrative build-your-own report system using data I made up, but that contains some real world factors. The visualization is in the middle and the usable measures are on the left side.
As a Federation, using the above chart, if I was curious about Jewish engagement by Affiliation I could drag in ‘Event attendance’ from the left into the chart and then adjust it by affiliation to see multiple lines of data over time. In the bottom chart, if I wanted to look at Population by age I could pull in the ‘Age’ demographic to see population split out by that variable. I could toggle it to see that variable for Families as well as Individuals.
A pragmatic v1:
The data collector (Federation or third party) could manually pull in data from 3-4 key organizations. Analytics resources at the data collector could pull together standardized monthly reports to share with internal and external constituents. Data can be gathered in an off the shelf CRM, like Hubspot or Salesforce where a central collector can pull in data in spreadsheet (.csv) format and then import it into the CRM tool. Most CRM tools come with some version of the visualization tools shown above.
Central Collector use case 2: Allow grantors to make decisions based on data Grantors, such as Federations, could use the system described above to help inform grant making decisions. For Federations a fully data based approach will never be a viable one, but systems of accountability based on things like a mutually agreed upon definition of engagement or some collection of Net Promoter Score (“NPS”) could inform how grant making happens on an annual basis.
A pragmatic v1:
Take one measure, like NPS, specify how grantees should ask it, and make the survey of some segment of their membership a prerequisite for their funding.
Central Collector use case 3: Enable centralized communal marketing A holy grail for our community is a system that individually understands the members of our community and is able to perfectly market the right set of services to them. Unfortunately, because of the challenges associated with disparate engagement, a lack of tools to collect data, and a lack of skill to market using that data we have made limited traction toward this vision.
The closest we’ve come (the I know of) is the PJ Library system we use to collect email addresses, zip codes, and the age of the people in the household for the purposes of sending them books. Although PJ Library is an amazing device to engage with Jewish content and serves as a great indicator of Jewish intent, it is mainly constrained to the families with young children segment of our population. It also is limited by the information the PJ partner collects and the systems they have to merge that data together with other information, and then market using both sets of data.
Our community needs a centralized system that earns the right to communicate and market to a wider swath of individuals. This could include, but is not limited to PJ Library. Sites like Jewishboston.com here in Boston or the broad nationally available event site, JLive.app, push in this direction. Their value prop for the collection of contact information is the perception of a centralized archive of events and content. They make it easy for operating institutions to configure events and for users to sign up. Jlive has even created a bridge for event data that is collected in their system to flow into a wide variety of CRM systems including but not limited to Hubspot and Salesforce.
' As a community it merits thinking about how we might centralize these mechanisms to form one central marketer who can communicate to a broader range of constituents. This marketer would be charged with a rich understanding of individual members of our community, and would also need to understand the optimal event/membership to market to them on behalf of partner organizations. A pragmatic v1: Whoever runs PJ Library locally, could independently collect data on its programs or through programs of its partners, integrate those data points back into its system, and more personally market to its email base. We could do a lot more with the existing systems we have before migrating to something richer.
Participant use cases: Operating Institutions These are institutions that have participants attend their events or become members of their institution. While the use cases for the central collector are important to understand as a likely funder of such an effort, the use cases for Operating institutions are harder to identify and gain confidence in, but are a prerequisite for success. These are the synagogues, JCCs, camps, and day schools that will need to semi-regularly submit information. Most of these institutions are under-resourced and most have at best dated systems for data collection. As a result, the use cases and subsequent value proposition for them is critical for a central collector to nail down.
Operating institution use case 1:
Leverage tools to visualize your performance
Most Jewish operating organizations don’t have particularly good tools to help visualize their own performance. Most have some form of financial reporting system that holds their organization to a budget that they can use to communicate with their board and funders. Most however don’t do much more than sporadically produce numbers associated with events. There is an opportunity using some of the tools described above to make the visualization of performance plug and play and give operating organizations an opportunity to easily see performance.
Picture a system like this:
After your Hanukkah event you have a stored list of names and emails.
The central collector creates a simple standardized form that can be populated with that information.
The operating organization uploads that information into the central collector’s system.
The system aggregates data from this event and combines it with what we know about the participants of this event to form a more complete picture of who the event attracted. The data is displayed at the aggregate level so as to not reveal information about individual members that the organization doesn’t know themselves. In other words, the system is using demographic data from multiple operating organizations.
Here is what a post event dashboard could look like: Info above could be customized depending on the organization’s interests A pragmatic v1: The local PJ Library operator works with 3 partner organizations to collect post event data in a single age segment. They cobble together that data to produce post event reports for each partner organization that reflects the range of data they’ve collected across all 3.
Operating institution use case 2: Gauge your performance against other like organizations Taking from the example above, picture a Chabad chapter who has just put on a very popular Hanukkah program. Hundreds of people attended, a good time was had by all, and lots of folks left saying they want to come back to future Chabad events. They build on the process above by conducting a post-event survey to ask a series of standardized questions about the event. A. How likely is it that you would recommend Chabad to a friend or colleague? B. How many new people did you meet at this event? C. How many of the nights of Hanukkah did you light candles? After collecting this information they could upload it all in a simple spreadsheet. In this model the central collector may have collected identical information from many different partner organizations. Upon submission of your own data the comparative data set could be shown to each participating organization. Here is an example: The benefit of understanding how your event compares to others and how your audience compares is that you can chart your progress and experiment accordingly. If Chabad runs a program each year, it can tweak the parameters of that event and see whether it has any kind of impact.
A pragmatic v1: Central collector chooses 1 event type where they make a concerted effort to collect data from multiple operating institutions. 1 week after collecting the data they send a personalized output to each institution with their performance vs others.
Operating institution use case 3: Get a fuller picture of who your constituents are In addition to data related to specific events, Operating institutions could establish a more holistic picture of the population served in general. If a synagogue submitted membership data to a central data collector they could get back incremental demographic data on all of the constituents they serve. This would allow that synagogue to better understand its membership and help it design programs that better fit member needs.
Conclusion Diversified journeys are going to make understanding the patterns of Jewish constituents more and more challenging over time. Data sharing has the promise of helping everyone in our community better understand the customers they serve and serving them more effectively in the future.
If Jewish engagement’s central data collectors want to earn the right to collect data from operating institutions they will need to make both an internal case and an operating institution-centric case for investment. Since there are limited case studies for data sharing, central collectors will need to be thoughtful about how they sell data collection to philanthropists, internal employees, and partners. Doing so will require both a long term aspirational vision as well as a more pragmatic short term approach. We would be well served at least experimenting with some of the mediums described above. We have a lot of challenges to overcome, but regardless of the exact solutions we need to embrace the importance of this mechanism and start to take action.'
In a future post The above analysis skirts the question of who is in the best position to build an asset like this. In a future post I’d like to grapple with the question of what kind of organization or potentially what third party is in the best position to not just build something like this, but to evolve it over time. Given the rate of change in the digital sphere, it’s particularly important for digital solutions to have a means of evolving themselves. This concept has implications for how our community thinks about building digital solutions in general. Leave a comment Share © 2023 Ari Sussman