Tallyfy Manufactory is an events lifecycle engine. Some people call it an “events infrastructure as a service”. We handle the heavy lifting when it comes to collecting, querying and triggering from events or time-series data that’s associated to people or machines.

It’s highly scalable, highly available and offered as an API-only service. We don’t offer any UI or BI, because there’s tons of those platforms already out there.

It’s designed for companies with existing data science teams and developers who want a vendor to do all the heavy lifting when it comes to events or time-series data, but want full control over analysis (like visuals or using existing BI tools) along with triggered actions. As such - if you don’t need all the features in Mixpanel, Heap Analytics, Amplitude, etc. - then Manufactory makes a good, massively cheaper replacement - assuming you can build your own visuals and analytics.

Manufactory handles the entire lifecycle of events from actions by authenticated users inside your app. The lifecycle is summarized by three stages - ingesting, querying and triggers:

1. Ingesting. Manufactory event ingestion is via a REST API or via a websocket - at any scale. Events can contain any amount of meta-data about the event, as well as user or profile information related to that event. This makes it a far lower-cost, barebones replacement for any event or time-series data collection app you might use today - like Mixpanel, Google Analytics, Amplitude, Heap Analytics, Snowflake, etc.
2. Querying. You can query all your data, anytime - as much as you want. There’s no limits on scale, frequency or type of query. People typically build their own dashboards in BI tools like Tableau, PowerBI, and leverage the skills of existing data scientists to query, merge and visualize data from Manufactory. You could even build visuals natively into your app. You can also get all the data we hold for you at Manufactory anytime, via an SQLite database file. This means all your data is yours - we never hold it hostage for any reason.
3. Triggers. Triggers allow you set a webhook to be emitted from Manufactory using any criteria you set. You can add any number of triggers.

​​ Pricing

Our pricing is based purely on the total amount of events we have stored for you. That’s all there is to it - there’s no other costs for queries, triggers, etc.

Pricing is calculated daily for the events we have stored for you at midnight (CST) every day.

​​ Keep a lid on costs via TTL’s

Most people want to keep all their events throughout history in Manufactory, however, you also can set events to have a TTL (time to live) which will auto-delete your events after a certain time e.g. after 12 months.

Setting a TTL for events saves you money in the long run - because your number of events (therefore your costs) will not keep growing forever - since events older than your threshold will be deleted automatically.

​​ Differentiators

We provide an “events infrastructure as a service” with the following differentiators and benefits:

1. Massively Lower Cost. You only pay for the total number of events we have stored for you. Our pricing starts at a minimum of $5/month. No other costs or limits exist - so you get unlimited querying, unlimited triggers and unlimited event storage.
2. (Almost) Real-time Triggers. Most event collections engines will not let you trigger webhooks in (almost) real-time from events you are ingesting. Since we offer this - you can use it for a variety of use cases, like rapid-response data prompts, emails, etc. with users within your app. An example of a trigger is - “if the same user fires the Settings > Upgrade event more than 5 times within the last 24 hours - then send a webhook to ANY_URL”
3. DIY Querying & Analytics. Given that most companies that collect events tend to have the skill-sets to create custom dashboards and custom visuals already - you can use any BI system of your choice to query, render, visualize and analyze your event data. Manufactory is best suited to sophisticated companies and teams that only want the engine and don’t need the visuals, BI, etc.

This is what Manufactory is not designed for:

• Logging. If you just want to collect anonymous or system logs - there’s many other logging services out there. Manufactory is ideally for events generated by known and identified people or known and identified objects (like sensors).
• Business users who need built-in analytics and UI visuals. We don’t supply any sort of interface for analytics or UI, other than to see and manage your data, of course. Manufactory customers use their internal skill sets (developers, data scientists and analysts) and existing licensing investments (for BI or dashboarding tools) to query and analyze their data.
• Events with no accompanying profile. An event without a profile is like a log entry with no attribution about who did that event. Whether that profile is a person (ideally) e.g. John clicked X, or a sensor e.g. Door 5 was opened - we need an actor for every event.
• Public websites. As already noted above - Manufactory was designed for authenticated users with profiles, not for anonymous users on public websites. If your website or web app has signed in users, it may be a good fit for that purpose.

If you need to chat about your use cases - please schedule any date that suits you via https://tallyfy.com/amit/ . We don’t have any sales people, so we’ll spare you the pain of sales and give you straightforward, tech-savvy answers to your questions.

​​ Structure

​​ Glossary

• A project is a way to subdivide your Manufactory organization into distinct sections for example, you might want to create individual projects for different products, apps or even sections of your app.
• An event is a data point that represents an interaction between a user and your application. Events can be a wide range of interactions. Each event will be linked to an actor profile.
• An actor is the specific individual, system or device that completed an interaction with your application which produced an event.
• Events and actors have properties, which can be changed at any time. For actors - we do not store a history or changelog of past properties or changes to properties - we only store the current version of properties.
• Each Manufactory organization will have it’s own orgID org_id and this ID will be used to create the schemas and during the authentication process for websocket connections. Note that each orgID gets a single, unique set of actor profiles. Therefore, each customer app = one orgID = 1 Manufactory organization.

​​ Related articles