Origin Source Codes are a common practice when organizing at scale. They typically indicate when an individual first encountered an organization, and can be used for everything from lifetime value to program valuations. If you’re new to Source Codes, make sure to read this first:
A typical implementation of origin source codes has a different source attached to every inbound source for your organization — signup forms, forwarded emails, partnerships etc. That source code is then attached to an individual when they’re first put into your CRM, and it should never change*. That’s what makes it a special source code — being the first one, and never changing. When you run reports, for example transaction reports, you then group them by the origin code, and you can see the lifetime value of everyone who came in with that code.
Fairly simple, right?
Well … if you’re dealing with perfect source coding, identical CRM implementations, and only one CRM of record. At Frakture, we don’t have that luxury — we have to deal with the ugliness of real world data and implementations. Specifically:
To deal with these intricacies, Frakture leverages our Timeline, and keeps track of each different origin source code and the CRM it came from. This includes changes to the origin code, and our best estimate of when that happened. Because people are accustomed to the phrase Origin Source Code from their CRM, we echo that name in our Timeline as a CRM_ORIGIN. But because of the above reasons, just because it’s called CRM Origin doesn’t mean that in Frakture it’s the ONLY Origin source code.
Sometimes multiple CRMs will have the same origin code … but that is often not the case, so that’s why we track it by CRM as well.
This may seem like an unnecessary complication, but there are multiple use cases for keeping many origin source codes. The design of our Timeline and Modeling infrastructure separates out the data from the model when discussing value. The data is as much information as we can gather about an individual, including all their origin codes. The model you choose lets you make business decisions about how to value that data.
Frakture deploys a number of native models — for this discussion though, two are relevant — CRM Origin and First Touch. CRM Origin is the model that most closely matches typical expectations of an Origin Source Code, BUT it factors in multiple CRMs, and changing origin codes. For lifetime value, it selects the first CRM origin code out of all of those, and then applies any overrides.
First Touch selects the source code from the first time someone has ever been seen, even if they may have a different Origin code in the CRM. This is common with partnerships or acquisitions, or other cross-organization work where the entry in the CRM may be long after the first time someone was seen.
As an example, Organization A (e.g, a C3 nonprofit org) may have a CRM that contains the origin code from a survey they ran in 2020, and Organization B (say, a partner C4 organization) may maintain a different origin code referencing their partnership with Organization A in 2024. Depending on who is looking at the data, “Lifetime value” may refer to either the source code from Organization A, OR Organization B … depending on who is looking.
The value of Origin Source Codes are thus in the eye of the Beholder.