* Marketing Cloud Engagement *

Why do you see a need for using redirect in CloudPages to track regular email clicks? Any link in the email, will normally get tracked automatically - unless the entire html code including the full <a href=“”> is placed in one ampscript variable. I would start by verifying your email code, before jumping into cloud page based workarounds.

Your other question of mailto: tracking is a different story. This will not be possible to achieve, since this is handled locally in the email client, and will not be sorted neither via standard tracking or with a workaround.

Got it - if you need every value, not the latest, then scrap the ROW_NUMBER part. But the batch-time pain is the real signal: SSJS is row-by-row and single-threaded, so parsing every subscriber's JSON in-journey will always be slow (your 20-min batches) and blow the journey timing. The fix is to get that work off SSJS entirely. Two reliable ways, both needing one change: land the related data as ROWS - a normalized child DE, one row per value keyed by SubscriberKey - instead of a JSON array in one cell. 

1. Best for 'all values': AMPscript at send time. Keep that child DE and in the email use LookupRows(childDE, 'SubscriberKey', subkey) with a loop to render all of a subscriber's values inline. Each send only touches that one subscriber's rows - no giant pre-parse job, nothing to time out, and it naturally handles however many values a person has. 

2. Or pre-flatten with a SQL Query Activity. It is set-based (whole dataset at once, minutes not hours), so it scales where SSJS cannot. Concatenate all values per person into one delimited field using the FOR XML PATH pattern - note SFMC's SQL engine does not support STRING_AGG, so FOR XML PATH is the way. Output a flat sendable DE. 

Either path removes the SSJS bottleneck; option 1 usually wins when the value-count per person is unbounded. 

If this sorts it, a Best Answer mark would help the next person hitting the same JB timeout wall 🙂

This is a really common modeling problem, and you are already on the right track with campaigns. The key realization: product interest is a time-stamped many-to-many (one person to many products, each with a date/source), so it should not live as fields on the Lead, a multi-select picklist loses the timeline and does not survive conversion. Two layers that work well together: 

1. Keep using Campaign Members for the 'raised their hand' events, it is the right call. Add a custom Product field (lookup to Product2, or a picklist) on the Campaign so each campaign is tied to a product, then a person's interest history is simply their Campaign Members: 'Product A campaign, January' plus 'Product B campaign, July.' Campaign Members work for both Leads and Contacts and survive Lead conversion, so the history is not lost when a lead converts. You can report interest-by-product by grouping Campaign Members on the Campaign's Product field. 

2. For a cleaner, queryable model, add a custom 'Product Interest' junction object: lookups to Product2 and the person, plus Date, Source/Channel, and a Campaign lookup. That gives you one time-stamped row per interest signal, trivially reportable as 'everyone interested in Product B since June,' and it drives scoring/routing far better than picklists. 

On the Lead-vs-Contact identity snag (the person could be either): the pragmatic pattern is to capture pre-conversion interest via Campaign Members, and once they convert/de-dup to a single Contact, hang the Product Interest records off that Contact. If you have Data Cloud, its Unified Individual solves the same-person-across-Lead-and-Contact problem natively. 

Since this is tagged Marketing Cloud: if you are on Account Engagement (Pardot), Scoring Categories are purpose-built for this, a separate interest score per product line, so one prospect can score high on Product A and low on Product B independently. Pair that with the campaigns above and you get both the engagement history and a per-product interest score. 

Net: campaigns (with a Product field) for the event history + a Product Interest junction object for the clean many-to-many, converge everyone to a single Contact, and use Pardot Scoring Categories per product if you have AE. 

If this helps, please mark it as the Best Answer so it is easy for the next person to find. Thanks :)