You need to validate complicated optimization ideas, it's seems to be fine extracting data from documents you already have, ask for missing info / documents and calculating numbers
I don't think that it's google's fault. Google sometimes trade ads on auctions, meaning they issue and HTTP request to partners asking "Hey, you want to show an ad here", and partner respond with price and HTML code, the highest bidder wins and HTTP code is inserted.
HTTP contains JavaScript, and theoretically anything can be executed within the browser (I've seen people mining bitcoins!).
Google can't monitor an execute every HTML snippet, but they doing pretty great job sampling responses and evaluating some of them. Fraudsters are smart, and trying to understand if the code is executed on Google's servers, but overall they are loosing.
It seems like a case where google's system didn't work.
Hi! We don't have plans to add Vertica yet. But if your team is willing to help or send PR we can reconsider!Feel free to reach out directly to me at [email protected]
Yes, just add more jitsu nodes. It's hard to answer how many nodes do you need (depends on transformations, CPU/RAM/etc), but you can count on thousands request per second per node at least
Overall, Jitsu tries to decompose (aka flatten) JSON as deep as possible. E.g. {a: {b:1, c:2}} will become a_b=1, a_c=2. If column is missing, it will be created. We don't decompose arrays so far
Mixpanel will store the data for you and do visualization. Jitsu just help you to get you data to your data warehouse.
Downside: you'll need to build all visualization by yourself. Fortunately that's easy with tools such as Looker, Mode, Metabase etc
Upside: you can do with your data whatever you want - built any reports, join with other datasets etc. You not limited by reports MixPanel team build.
In reality, Jitsu and MixPanel could co-exist. Jitsu support s MixPanel as a destination (e.g. you send data to Jitsu ; Jitsu sends it to MixPanel and data warehouse).
1. Thats exactly the reason we have native connectors for Facebook and Google Ads (we didn't use ones from Airbyte and Singer). Jitsu can pull any combination from FB/GAds — it's almost like SQL! Airbyte/Singer just can't do that. Later we're going to vet other connectors too and decide if we need to re-implement them
The same way as Kafka. Jitsu nodes (=collection agents) writes to write ahead log, and then either sends data to destination right away, or sends data in batches.
We have some overlap. In simple words: a Singer + DBT, Jitsu is Event Collector + Singer + Airbyte.
Meltano will pull data from Singer connectors and do transformations, but they won't run Airbyte connectors, and you can't push data to Meltano
Jitsu will use Airbyte or Singer to pull data, and you can push the data to Jitsu. But Jitsu won't run DBT transformation. Although we can trigger DBT cloud jobs: https://jitsu.com/blog/dbt-integration
There's always a tradeoff. By describing our company as "alternative to X" you saving tons of time by explaining what you company does. People are overloaded with information, and average attention span very short. But I see the disadvantages too! We have an internal debate about tagline a few months ago, and essentially decided to go with "Open-source alternative to Segment". But it wasn't an easy decision!
However, I think that the product matters the most. You can change the tagline in a few clicks. Can't say the same about the product
We call it "push" (you send event to Jitsu) and "pull" (Jitsu pulls data) integrations. Technically speaking, push integrations are outnumbered. But that's because we took advantage of other open-source projects (Airbyte and Singer) to implement them.
Our core is push integrations, that's the most complex part of the system. We see "pull" integrations as an additional feature that helps to enrich the data after events made it to DHW