Mastering Data Integrity with SKU & Tracker

Welcome to this edition of the Click and Pledge's Fundraising Command Center podcast where we talk the why, the what, and the how in the Click and Pledge's ecosystem.

And today we are continuing our focus on the what series. We're going to be diving deep into two, two incredibly powerful features that are just absolutely essential for data integrity and automation. The strategic power of SKU, that's the stock keeping unit, and our essential tracking tool, Tracker.

Right, because when people think about online fundraising they're so often focused on, you know, the design and the conversion rates. But what happens after the click? That's where the real work begins.

That's where it all happens and it's where so many organizations lose every single week.

So our mission today is to give you a bit of a shortcut. We want to show you exactly how these tools let you do this granular tracking and build robust automation.

We're translating every dollar raised, every single click in a perfectly organized, clean data records right inside your Salesforce environment.

So think of it like this. We're gonna show you how to set up the rules so that when a donor gives, that transaction is automatically coded for accounting.

Right. And assigned to the right campaign and it sends out the perfect personalized thank you note. Our goal here is to just eliminate manual data cleanup entirely.

Okay. So let's start with the fundamentals then because while both Tracker and Skihi handle tracking, they operate at, well, very different levels. Tracker is probably what most people are familiar with.

Yeah. Tracker is the traditional high level tracking mechanism. It's really just concerned with the source. Where did this donor come from?

How did they find me?

Exactly. And it works by adding a simple variable to the URL parameter. We use the format TRK and then your value.

So, if I have a big email appeal going out, I would just add something like TRK evolves email appeal twenty twenty four to end of the URL.

That's it. Exactly. Or let's say you're AB testing different email layouts. You could use TRK EMAIL A versus TRK EMAIL B. The key is that tracker is read the second the payment button is clicked and that value captures the overall source.

It answers that one big question, how did the person find the payment form?

So it's the channel, it tells us how the donor you know walked in the door.

Correct and that value gets posted directly to Salesforce and to your connect reports giving you that high level campaign visibility.

Now, SKU stock keeping unit, that's a different beast entirely. It comes from retail, which, I think might sound a little strange in the non world.

It does at first, but it is remarkably effective. I mean, SKE is just a unique product ID for inventory management. I love the grocery receipt analogy because we all get it.

Right.

When you look at your receipt, you don't see manufacturers select premium 16 oz can of creamy chicken noodle soup. You just see a short code like CMPBL CHKNNDL SOP.

The SKU.

That's the SKU. Yeah. It's a coded shortcut. A dense packet of information.

And that density can be processed really, really quickly by system.

Precisely. And in our ecosystem, we leverage that. Every single payment form item you create, a general fund donation, an event ticket, a membership, it can have a user defined SKU.

And that's the big difference, isn't it?

It's the crucial distinction. Tracker is the overall source, but the CU tracks the individual specific items within that one transaction.

So if a donor buys three different things, we get three different SKUs?

Three distinct SKUs, each one enabling its own unique automation.

Okay. So if the CCU is basically an instruction manual for Salesforce, then the planning has to be the most critical step. You have to write the instructions perfectly.

You absolutely do. The first step, and we really recommend this, is mandatory. Grab a blank sheet of paper and just be ruthless. Write down every single distinct item, service, or fund your organization offers that needs unique reporting or unique follow-up.

Every single one. Restricted funds, membership levels, ticket types.

All of it.

That seems like a pretty high upfront administrative hurdle. Mean, if I'm a big organization with dozens of items, am I really writing 50 different codes and 50 rules?

That's a fair challenge. But that upfront effort is what saves you hundreds of hours of manual admin time later you're investing in your data structure.

Okay. So after I have my list, what's step two?

Step two is determining the Salesforce needs. For each item, ask, does this donation need specific record type? Maybe program income? Does it need to populate an internal accounting code on the opportunity?

So you define the destination fields.

Exactly. And step three is the donor experience, the patron needs. Does buying a raffle ticket need a receipt that says not tax deductible while a general gift needs a full tax letter? The CU dictates which autoresponder gets sent.

Okay. So once we have that strategy, then we get into the coding. What are the best practices we suggest for building those sesu codes?

Consistency and clarity are everything, and the structure should be consistent across your whole organization. We recommend breaking the CU into syllables using dividers like dashes, underscores, or colons.

So an example might be Don General website.

Perfect example. That structure lets our system parse the information really easily. And organizationally, we suggest structuring those syllables from the biggest group down to the smallest.

Like a filing system, you want your broadest category first.

Yes. So if all your income is either a donation, an event, or a membership, you start with DAWN, EVT, or MEM. That's your master category. Then you get more specific.

So instead of building Fund DAWN, we'd call it DAWN Restricted Building.

Precisely. Because now you can search for all Don restricted items and you capture everything that needs that specific accounting treatment no matter what the fund is.

And you have to be consistent. If you use Don, don't use Gift somewhere else.

You can't. It'll break your logic. And a few technical things. SCS aren't case sensitive, but we really recommend using all caps for readability.

And keep them as short as you can, right? Even though the max is 100 characters.

Yeah. And most importantly, avoid confusing syllables. If you use mail in one SKU's, don't use email in another if you're planning on using starts with or includes criteria for your automation.

Oh that makes sense. That could lead to some frustrating miscategorization.

It absolutely can. Now to add even more granularity we have the concept of SKU suffixes. This lets the system append extra info to the base cue for on the fly.

And this often connects to a conditional custom question on the form, right?

It does. A classic example is the tribute donation. The base item might just be Don General. But when the donor answers the question, is this in honor or in memory of someone? The system can append that answer.

So the final SKU becomes Don General Honor.

And that dynamic concatenation lets you map specific tribute fields and crucially trigger those special notification letters.

Yes, and a critical recommendation here, if your answers are fixed values like in honor or in memory, we strongly suggest using SKU rules for mapping that, not custom question mapping.

Why is that?

It just keeps your back end data structure much cleaner. You just create a rule for each possible suffix. It's much more streamlined.

Okay. Let's connect these codes to real internal operations. We need some concrete examples of how the SKU schema saves time for the admin team.

Sure. Let's take three common scenarios. First, restricted funds. If you're legally required to track funds separately, using SKUs like Don Medic Research and Don Medic Patient ensures that separation.

So the automation rule just says what?

The rule says if the SKU starts with Don Medic assign accounting code 4001 but if it also ends in patient then populate the designated use field with direct patient care.

And that is guaranteed data integrity for your financial reporting. You're not relying on someone reading donation comments.

Never. Second, event and membership management. You sell a family membership, the SKU might be MEM Family 2025.

Okay.

This triggers a rule that creates the opportunity with the membership record type. It sets the membership level field to Family and it triggers a custom welcome packet auto responder.

So the single transaction is classified both financially as income and functionally as a membership?

Absolutely. And the third example is campaign hierarchy. This is where tracker and SKU work so well together. Mhmm. The tracker tells you channel may be TRK Facebook ad.

Right, how they got there.

But the SKU, say FBB pet sponsor, confirms which specific sub campaign the donor responded to. This allows items in a single basket to be assigned to different child campaigns, building funds, scholarship fund, and it all rolls up perfectly to the parent campaign.

Wow. Okay. That solves the whole roll up reporting problem. So we've designed the codes, we've mapped their function. Where does this code physically live on the platform?

The critical rule is this: wherever money touches the platform, the option to set the SKU is there.

So we're talking connect forms, the virtual terminal, and definitely Swiper One, the mobile app?

That's right. And for Swiper One users, there are multiple layers of control. You can set a default SKU for basic cash register sales but if you're using the integrated store manager every single item in there can have its own SKU.

Even with options like a t shirt in different sizes.

Yep, each size or color can have a slightly different suffix giving you a different inventory code. That level of detail even on a mobile device is what elevates your data quality.

Okay, this is the moment of truth. We've planned the schema, we've put the sexy you on the form, the transaction hits Salesforce, how does the automation actually work and what's the processing order we need to know?

Right. So when the data arrives in Salesforce, our donor management consults the SKU rules you've set up in Click and Pledge settings. These rules determine how the records are created and then updated.

Let's look at creation first. Where are those rules?

They're under CMP settings in the Opportunity section. Here, you use the SKU to define how the opportunity is initially created. Setting contact roles, choosing the record type, is that a donation, event, membership, and setting the primary campaign.

Now, for organizations using NPSP, the Non Profit Success Pack, this is where we have to flag a really critical detail about naming conventions.

Indeed. If you're using NPSP, you need to know that NPSP has its own automation for naming the opportunity. And if you have that enabled, the NPSP logic will override any naming rules you set in our CMP settings.

But if you use only the CMP naming

Then we offer some unique options like dynamically, including the event name and attendee name right in the opportunity name, which is so helpful for ticket tracking.

Okay. So CMP settings control the creation. But for that maximum flexibility, that guaranteed data setting, we need to talk about custom mapping. Where does that live?

Custom mapping, which is in CMP settings, custom mapping, then SCOU map. This is where you set rules to update the opportunity record after it has been created. Understanding the processing order here is, everything.

Okay, walk us through that sequence one more time because this is the fail safe, isn't it?

It is. So three steps. Step one: Donor management creates the opportunity based on the payment data and your initial settings.

Done. Record exists.

Step two: NPSP automations run. This is where NPSP sets its default, does its roll ups, all that stuff.

Okay.

Then, and this is the key step three, after all of that, the custom mapping update runs.

Ah, so custom mapping runs last. It means if I have a SKU rule that says, if SKU is DON restricted BLDG, set the accounting code to 4,005, that rule will override anything NPSP might have set by default.

Precisely. The custom mapping SKU rule is the final word on that record. It is your fail safe for guaranteed data integrity. And you're not limited to just the opportunity. You can map that SKU value to any field on the account, contact, or opportunity.

That is true, data integrity. You can make sure your critical financial fields are always populated correctly no matter what.

And that power extends to dynamic customization. Let's go back to that alumni example.

Right. The donor buys the pencil item and we ask, Are you an alumni?

If they say yes, the system concatenates that answer. The final SKU you becomes alumni pencil. You then have a rule that says, If the SKU contains LMNI, assign it to the twenty twenty five Alumni Outreach Child Campaign. The separate rule can fire, saying, if the SKU contains pencil, assign it to the school supplies fund child campaign.

So one transaction is now accurately contributing to two different low level campaigns. And because of the hierarchy, it all rolls up perfectly to the parent campaign. That makes executive reporting clean and instant.

It simplifies the back end immensely. But let's bring it back to the donor because this final piece of automation is maybe the most impactful.

Moving beyond just the generic receipt.

Way beyond. By setting SKU based rules you can send highly specific auto responders. A ticket buyer gets one thing, a scholarship donor gets a thank you that talks about the program's impact, and we strongly recommend using these rules to trigger a follow-up email after two or three days.

Why the delay? Why not send it right away?

That delay lets you send this powerful message of confirmation and impact. It removes any barrier of doubt from the donor's mind. Think about a donation for a meal program. You don't just send the receipt. Two days later, an email goes out, triggered by the Don Miele Scowie, with a photo of the food being distributed, and a message.

Thank you Sarah, your donation arrived and fed 10 families yesterday. That personalized, timely, specific confirmation, driven entirely by the SKU, is the ultimate effective use of automation.

That is the ultimate payoff. We started by saying SKU and Tracker are about collecting money, but it's clear they're the strategic difference between just collecting money and collecting meaningful, actionable data that drives your future strategy and builds those unbreakable donor relationships.

Absolutely. We really encourage you to take this and challenge yourself. Think about how much more efficient your Salesforce reporting would be if every single type of incoming gift had a clean, specific SKU mapped instantly to the right financial and functional fields. That proactive data mapping is the key.

For more information about this and all Click and Pledge products, make sure to visit clickandpledge.com and request for a one on one training or demo. Whether you are a client or curious about our platform, just ask us and we will gladly get together with you to chat.

And don't forget to subscribe to this podcast to stay up to date with all the latest and greatest features of the Click and Pledge Fundraising Command Center.