JENTIS Reviewed: What Twin Server and Synthetic Users Actually Deliver

What JENTIS does differently

A classic server-side build has several parts: web container, server container, CMP, plus the wiring between all three. JENTIS bundles that into one platform. A script in the front end, the processing behind it, and the forwarding to Google, Meta and the rest from there.

The technical core is called Twin Server and is described by the vendor as patented. The idea: rather than maintaining a separate API integration per destination, JENTIS mirrors server-side the same behaviour each vendor expects in the browser. That is why new connectors appear faster there than with a per-API approach.

One consequence matters most to you: what goes to Google or Meta is decided by a rule inside JENTIS, not by a script in the visitor's browser. Data reduction happens before dispatch, not as cleanup afterwards.

The platform is ISO 27001 certified, vendor and hosting are in Austria, and the homepage puts more than 1,300 websites and apps on it.

Synthetic Users, and what they really are

This is the feature that puts JENTIS on shortlists, and the one most often misread.

When a visitor declines consent, JENTIS does not measure them. Instead a model assigns them to segments and infers their likely behaviour from the data of visitors who did consent. The documentation cites up to 70 percent of otherwise lost data reappearing in reporting this way.

Three things belong alongside that.

Modelled data is not measured data. It is an informed estimate. For channel-level budget decisions that is often enough, for "did this one campaign work" it sometimes isn't. Both figures have to stay separately visible in reporting, otherwise somebody optimises against modelled values a few months in without noticing.

Quality depends on your consent rate. The model needs consenting visitors as its base. At a 40 percent consent rate you get weaker estimates than at 70 percent. A better banner therefore stays the first measure, not the modelling.

Google does something comparable at no extra cost. Consent Mode v2 models conversions for non-consenting users inside Ads and GA4, free of charge, as long as the tagging underneath is set up properly. The difference is reach: JENTIS models across platforms in its own data, Google only inside its own ecosystem. Whether that difference carries the price premium is the actual question.

JENTIS states the feature was developed with data protection lawyers. Two points still belong in your documentation before launch: the legal basis for the modelling, and how modelled values are labelled in reporting. Your legal team settles both, not the vendor.

How we scored it

Four axes, the same ones every tool in our catalogue gets.

EU data sovereignty 5.0. The only five in this category. Vendor in Austria, hosting in the EU, a contracting party under European law. No third-country transfer to justify.

Data quality 4.5. The first-party build makes events more resilient against blocklists, and field-level reduction stops raw data from leaving at all. The half point comes off because part of the reported reach is modelled.

Value for money 3.0. Enterprise level without a published number. For mid-market setups the ratio is worse than with the lean alternatives.

Ease of use 3.2. The lowest score. The platform is powerful and it shows during setup: its own vocabulary, its own logic, a learning curve a GTM-fluent team does not skip.

Pricing: what is public, and what isn't

JENTIS publishes no prices. There is no plan page with numbers, the route runs through sales.

Directories such as Capterra cite an entry point of around $199 a month, though dated July 2025 and with no indication of what volume that covers. Treat it as a ballpark, not an offer. We have no confirmation of it, and it appears here only because it turns up in every search.

Practically, this means a comparison against stape.io or your own Cloud Run is only possible after the first sales conversation. Walk in with three numbers and it stays short: expected monthly event volume, number of domains, number of destinations.

Where JENTIS wins

When procurement requires a European contracting party. That requirement is more common in regulated industries than the market pretends, and it rules out most alternatives. JENTIS is often the shortest path through the review.

When data minimisation has to be provable. Rules at field level, applied before dispatch, documentable. That is a different thing from a filter somebody added to a container later.

When many domains hang off one build. The architecture is designed to scale across domains, which is exactly where hand-built sGTM setups turn into a maze.

The vendor cites customer statements alongside this, including Pixum at 44 percent more orders and Playmobil tracking over 97 percent of orders. Both figures come from JENTIS rather than from us, and as with any vendor reference, the comparison setup next to it is missing.

Where it hurts

Switching means rebuilding. This is the point we make most plainly. With stape.io a standard GTM container runs, and you can move it to Cloud Run or your own hardware with the tagging build intact. With JENTIS the platform is the system. Leaving means rebuilding the tagging layer. That is not an argument against JENTIS, but it belongs in the decision, because it sets your negotiating position at every renewal.

No price without sales. For a business case that needs approval up front, that is tedious.

The learning curve is real. A team that knows GTM does not yet know JENTIS. Budget onboarding time, or bring in somebody who knows the platform.

Modelled reach can create false confidence. When a dashboard reads 97 percent, few people ask which share was measured and which was estimated. That question belongs in your acceptance criteria.

JENTIS vs stape.io vs your own sGTM: which fits when?

• If you need a clean server-side setup and DevOps capacity is missing, then → stape.io. Faster, cheaper, no platform lock-in.
• If legal or procurement require an EU vendor with field-level data reduction, then → JENTIS. That is precisely what the platform was built for.
• If compliance requires the container inside your own tenant, then → your own Cloud Run. Both managed routes drop out at that point.
• If your core problem is a low consent rate, then → fix the banner first. A better CMP setup and Consent Mode v2 cost less than a platform decision and move the same metric.
• If you run many domains under central governance, then → price JENTIS against a centrally managed sGTM. From roughly a dozen domains upwards the maths gets interesting.

Transparency

We are not a JENTIS partner and take no commission. Our declared server-side partner is stape.io, listed in the imprint. That is why this piece names the platform lock-in so plainly, and equally a reason to read it sceptically.

So the recommendation above comes with an explicit condition: where the requirement reads "European vendor, field-level data reduction", JENTIS beats our own default tool. We write that down because it is true.

What to decide it on

• Who sits in the selection process? With legal in the room the ranking of criteria changes completely. Without them it usually comes down to effort against benefit, and an sGTM setup is hard to beat on that.
• What is your consent rate today? Below 50 percent the biggest lever is the banner, not the modelling. Measure that before buying a platform.
• What happens in three years? Ask the sales team specifically what leaving involves and which configuration you can take with you. The answer says more about a vendor than any feature list.