How long should HubSpot last-touch attribution last in B2B SaaS? How to choose an expiration window

Expire a last-touch value on a rule tied to the contact's buying cycle. In the HubSpot builds we run for B2B SaaS teams, that means a window somewhere between 90 and 180 days, with a reset when a closed-lost contact re-engages. Freeze first touch unless you report by sales cycle.

Most first-touch and last-touch setups in HubSpot work the same way. A conversion event, such as a list add in a sequencing tool or a connected call, writes a value to last touch. If first touch is empty and last touch is known, the workflow copies last touch into first touch once and never overwrites it. The mechanics are simple and they hold up. Nothing in them says when a value stops being true.

That gap shows up the first time a contact comes back. In some databases contacts go closed-lost and return two or three times. Say the first touch was paid search, the deal closed-lost, and outbound brought the contact back. Credit goes to outbound, with paid search as the origin. If the contact goes closed-lost again and returns through an inbound form, the credit should go to inbound and outbound, and paid search should have aged out. A last-touch field with no expiration still points at whatever wrote to it last, and every report built on it inherits the confusion.

Attribution fields are only as useful as they are current. The rule that keeps them current is a reporting decision, and the person building the workflow should not make it alone.

A shorter window empties the field sooner. A longer window keeps stale credit alive. Those are the two failure directions, and the right setting sits between them for your sales cycle.

Take a 90-day window. A contact touches your site, goes quiet for four months, then books a demo. The opportunity opens with only the demo form in last touch. That is accurate and often unhelpful, because the earlier touches that warmed the contact are gone from the field. Take a 180-day window, or 200. You keep more of the warm-up, and you also keep touches that no longer explain anything, such as a webinar attended before the contact's previous deal was lost.

The number matters less than people expect. In the build we are running, the options on the table were 90, 150, 180 and 200 days, and our position was that any of them works as long as everyone agrees which one is live. Leaving it to whatever default the workflow shipped with is the one choice that fails.

Compare the window with your sales cycle before anything else. If a typical deal takes longer to close than the window lasts, last touch will already have expired on those deals by the time they close, and the report will under-credit the channels that ran early.

A fixed window is the simplest to build and explain. A scheduled workflow checks how old the last-touch value is and clears it past the cutoff. Everyone can predict what it will do.

A re-engagement reset ties the cleanup to the lifecycle. When a closed-lost contact restarts, the last-touch value from the previous cycle is cleared. That matches how people think about a deal, one buying cycle at a time. It has a flaw. A contact who re-engages only 20 days after a previous touch has told you something useful, and a reset that fires on lifecycle restart alone wipes that out. A workable combination clears on the window and lets a lifecycle restart reset the value only when the previous touch is old enough to be stale.

Pick the fixed window when your sales cycles are fairly uniform and your database rarely recycles contacts. Pick the reset when contacts come back after closed-lost often enough that a calendar cutoff clears values at the wrong time.

There are two defensible answers, and the people who built the workflow can disagree about them in good faith. We saw exactly that. The consultant's view was that first touch is historical data: once it is stamped, it does not change. The client's instinct was that a contact who re-enters the lifecycle after closed-lost should get a new first touch, because the new cycle is a new story. Our position on that call was that there is no right or wrong, only options and consequences of both.

A frozen first touch answers one question: how did this person first find us? It is stable, it is easy to audit, and nobody will ask you why it changed. It cannot tell you what brought the contact back, which is often what the pipeline report needs.

A first touch that resets with each cycle answers the second question and gives up the first. The history of how the person first arrived disappears, and a contact on a third cycle looks like a fresh lead in the report. If you want both answers, keep first touch frozen and stamp a separate field at each lifecycle restart with the source of that cycle. Two properties cost a little more to build and spare you the argument.

The same split came up in a Salesforce event program we support. A deal sourced by one event can later be influenced by a second event the contact attends, and without a tag that separates source and influence, the report has to pick one. Origin and cycle need separate homes in both platforms.

Four facts decide it: the length of your sales cycle, how often contacts come back after closed-lost, who reads the report, and what you will do with the numbers. The table at the top of this article shows how the combinations resolve.

Start with the sales cycle. A window shorter than the typical cycle blanks the field mid-deal. Then count recycles. Pull a sample of closed-lost contacts from the last year and check how many came back and how long they stayed away. If few came back, a fixed window is enough. If many did, you need the lifecycle rule.

Then ask who reads the report. Marketing wants to know which channels earn credit for pipeline. Sales leadership wants to know which cycle produced the deal. Those are different questions and they point to different first-touch rules. As we put it to the client, decide what you want to report, and the process will be a consequence of that.

Last, test the rule by hand before building anything. Take a handful of contacts who recycled, write down what each field should say under your rule, and ask someone in sales leadership to agree with every answer. If you cannot get agreement on five contacts, no workflow will fix that.

Five decisions need an owner. First, the window length, and whether leadership has agreed it or someone only remembers agreeing it. Second, whether the window runs from the last touch or restarts with the lifecycle. Third, whether first touch counts only conversion events or any activity, such as an email sent. A first touch that counts any activity fires earlier and more often, so the two definitions produce different histories for the same contact. Fourth, how pipeline value is split between first and last touch. A 50/50 split is the simplest place to start, and leadership has to approve whatever you pick. Fifth, where the report lives. If it sits in a BI tool outside HubSpot, the BI definitions have to match the property rules.

Get the answers in writing. We have watched a number remembered as agreed turn out to be a number someone meant to double-check, and a cleanup workflow built on it is rework waiting to happen.

Within limits, yes. Two properties hold two touches, so the model they support is a split between those two, 50/50 at its simplest. Anything that credits a middle touch needs the full event history, which these fields do not keep. In another engagement the team proposed a separate attribution data layer that captures the full history for exactly that reason. We would scope that as a second project.

Before you build any of it, write the rule in two sentences: how long last touch lives, and what first touch means. If you cannot write both without a qualifier, you are not ready to build.