Your brokers. Your bucket. Your format.
Kafka for the streams you consume, S3 for the data your warehouse loads. You already run both. The question was never whether events can reach them - it is how much glue you maintain to keep them arriving with the scores already attached.
0.0on G2Publish to brokers you already run.
Ordered routing rules decide which record goes to which topic, first match wins, and anything unmatched falls to a default. Intempt never creates a topic on your cluster - a workflow aimed at an undeclared one fails instead of inventing it.
- Ordered topic routing, first match wins
- Declared topic list; nothing is created for you
- Partition key defaults to the record id and is yours to override
Or land it in your own S3 bucket.
Point it at a bucket, a region and an optional prefix, and authenticate the way your security team prefers - an IAM role assumed with an external id, or an access key pair. The secret is write-only, so it is never readable back after saving.
- IAM role with an external id, or access keys - one or the other
- Your bucket, your region, your prefix, your KMS key
- On Kafka: JSON or Avro with an inline writer schema
What it takes to get a useful record onto your own topic
Both products can put an event on a topic or in a bucket. The difference is how much of the pipeline between the event happening and a useful record landing you own and operate.
| What lands on you | On Segment | On Intempt | Who does it |
|---|---|---|---|
| Raw event onto a topic | Native, this is the core product | Native, a Workflows destination | Nobody - it runs |
| Only records matching a condition | Filter in a transformation, or downstream | A routing rule on the workflow node | Data engineer, once |
| Record carrying a computed score | Model in the warehouse, sync back, then publish | The attribute is already on the profile | Nobody - it runs |
| Different record types to different topics | One destination per topic, or branch in code | Ordered routing rules on one node | Data engineer, once |
| Land the same records in S3 for the warehouse | A separate warehouse destination to configure | An S3 destination on the same canvas | Data engineer, once |
| Stop publishing when consent is withdrawn | Enforce it in your consumer or upstream | Consent is checked before the send | Nobody - it runs |
Neither product is doing anything exotic here. The rows reading “Nobody - it runs” are the ones where the work already happened before the record reached your cluster.
Connect every trusted source.
Plug into the tools your team already runs on.
%201.svg){kind=logo}
%201.svg){kind=small}
Your customer data stays yours, and stays secure.
The teams that made the switch
We were losing visitors before they signed up. Intempt's personalized experiences changed that - we started meeting people where they were instead of guessing. Once they're in, Intempt's automated email takes over and keeps the relationship moving. Acquisition and retention finally feel like one connected motion instead of two separate problems.
Jim Stromberg, CEO
StockInvest
Case Study
StockInvest needed to turn anonymous traffic into registered users before any retention strategy could work. With Intempt's Experiences, they personalized the anonymous visitor flow, surfacing the right content and CTAs to boost signup conversion. Once users signed up, automated Journeys nurtured them through onboarding and deeper engagement, steadily increasing lifetime value.
Frequently asked questions
Enriched records on the topics and buckets you already run.
No. You declare which topics a workflow may publish to, and a workflow aimed at anything else fails rather than creating it. Credentials are never readable back through the interface after saving.
Records where your systems already look for them.
Publish to your own brokers and your own buckets. Free to start, with no destination caps on any tier.