In a perfect world, how would the charting in Periscope work? How would you want to go from getting 80% very fast, to going to 100%, in the same software?
Hi, thanks for the reply! Actually, apologies for throwing your name next to tableau like that. I think your product does a great job incorporating things like R/python scripting to allow more flexibility in how data can be manipulated within the product. In this sense I prefer periscope to tableau (an in many other senses actually).
A problem I encountered (granted over a year ago) was creating grouped bar charts with confidence intervals. Bars were grouped on some discrete x axis labels. The suggested solution for confidence intervals on grouped bars was to use a scatter plot to draw the confidence intervals, but this clumped them all on the xlabel position, not in the center of each bar. matplotlib for example treats the visualization as an object, in which case it makes a lot of sense that to add confidence intervals just query the bar objects for their positions and place line segments of desired widths in the center of the tops of the bars (or wherever, you have full control over this). So in general, a marriage of these two paradigms, quick development of a visualization based on data, but then the ability to switch to viewing and manipulating the visualization as a collection of instantiated objects with full control over their attributes.
I am open to revisiting over any development periscope has made to this end.
Yeah, the hack you described for CIs is typical of "80% charting". We have a list of probably thousands of longtail visualization requests and we're way past the 80/20 point.
These days customers who want to go 100% use the Python/R editors and do their custom visualization there. So you do your SQL query like usual, but then pipe it to Python/R for the visualization. Have you tried that, and has it worked for you? Or do you prefer another model?
Maybe try Muze to be able to build all those long tail viz :) - given that you don't have to think of any viz in Muze as a chart type - but rather compositions through layers. Would love to talk to you guys!
If you don't mind, could you list the other things that make you prefer periscope to tableau? Also when you say R and python scripting, do you mean using them to prepare your data or to do something else?
It's likely that the largest advertisers don't use the self-serve ad manager. They call their rep who operates the system for them. This is why the self-serve ad managers for AdWords, Facebook Ads, etc. are all pretty unloved.
Ex-agency guy here, now client side. This is not the full picture.
Just because brands outsource media management to agencies doesn't mean the many business reasons for improving the UI go away.
As someone who has collaborated with Google engineers and PMs on such things before, I can confidently say they care quite a bit.
You see, agencies margins are in part dictated by how much time it takes to do "low impact" but "mid-high" effort activities like reporting and day to day campaign management. It takes real people hours to do those things and if to platforms are delivering otherwise comparable performance, at the agency level, they will push towards things that deliver higher margins. Which might be the platform that lets them get the most done with the least effort.
And I'd also add that i think AdWords and FB have some of the most user-friendly interfaces for such an advanced and massive feature set compared to other players in the industry.
Periscope Data cofounder here. I wouldn't say we're "allergic" necessarily. ;) Like a lot of startups, we're very young and haven't gotten around to building out the website as much as we'd like to.
`jplitz and `ajones are right. As of now we support MySQL, Postgres, Amazon Redshift, Vertica, SQL Server, Oracle, MemSQL, Sybase, Exasol and Google BigQuery. We add more all the time.
(Full disclosure, co-founder of Periscope Data here.)
Periscope Data supports cross-DB joins. We cache the data in our own clusters so queries run really fast, and also so you can do things like join across databases and upload CSVs.
I'll just say upfront that I'm the cofounder of Periscope (https://www.periscope.io/) which is specifically marketed at data scientists, so I have a horse in this race. :)
There are two kinds of charts: Charts designed to find information, and charts designed to sell information. The latter are often gorgeous and many-dimensional: Heatmaps, animated bubble charts, charts with time sliders, etc. And by all means, if selling the data is required, then sell it with the best tool for the job.
As for actually investigating the data, it's usually a lot of tables, lines and bars. They're simple to understand, and there's no cleverness in the visualization that might hide critical information.
To answer your questions, at Periscope I've seen:
1. A line graph of amplitude over time. You should see the frequency emerge clear as day. If you want to calculate frequency explicitly, you could overlay a second line with its own axis. Again, super simple, but gives you the answer directly.
2. I've seen a lot of fancy graph visualizations, but nothing that makes me happy. Depending on what you want to know about your graph, maybe a simple table with a structure like:
[node name][node name][weight]
Or:
[timestamp][node name][node name][weight]
A pivot table on top of this data, transoforming the second node column into the table's horizontal axis, can also be useful.
3. OK, obviously I think Periscope is a great choice here. Loads of data analysts use it to visualize time series data on many tens/hundreds of billions of data points.
That said, other good choices are: Excel, R/Stata/Matlab, gnuplot, Apache Pig. And for the data storage itself, IMO Amazon Redshift is unparalleled.
While working on signal processing and some graph data structures, I was looking for a simple code snippet to add in my code and be able to quickly visualise the data in my web browser. I was tempted to implement it myself a bunch of times, but I never got the time to actually do it.
What I ended up doing is dumping my data points into a CSV files and use excel, which was really bad if I had more than 50k data points (I am on running Mac OS X).
Periscope is amazing btw.
For ping-and-visualize, I'd recommend a tool that'll give you raw access to the underlying data. Some choices are https://amplitude.com/ and https://segment.com/. Happy to chat about pros and cons if you're curious -- harry@periscope.io.
There needs to be a route from the internet to your DB, yes. Sometimes this works because the DB is in the cloud, or sometimes a port or SSH tunnel is opened into a local network.
Unpaid employment taxes too -- the cxx levels, the investors, the board, and every single employee who paid any other expense instead of paying the US gov their money.
I wrote more about this in the past, but even bookkeepers have been held personally liable. The government considers employment taxes to be paid by the employee on the date the employee receives his or her paycheck, and the employer is merely holding on to that money temporarily. It seems quite unwise to fuck with this.
No I meant that in order to avoid any possibility of personal liability the C team would give up and liquidate the company much faster than the UK where more efforts might be made.
I have direct experience of this - I even chaired a share holder meeting about a refinancing.
The US states take unpaid employees very seriously. Think about it from the employee's point of view - if the company can't make payroll one week, you might be tempted to let it ride until next week. If they again can't make payroll, you've put 80+ (120+!) hours into the firm with no payment. I certainly wouldn't be happy in that situation.
This also partly aligns with it being very easy to fire people in the US. The government therefore views the employer as having a perfectly reasonable option in the case where they are truly short of money: fire the employees you can't afford to pay before they work the hours you don't have money for (or something halfway, like giving people a non-optional offer to go down to half-time). In most cases that can even be done with no notice, though that isn't very nice. But it is at least seen as more honest than stringing people along ostensibly working for a salary they aren't going to get.
In practice one way to handle this is keep one payroll cycle's worth of liquid cash "locked up" in an account that is reserved for payroll and which you don't dip into for other expenses. So even in the worst case the last paychecks can be sent out before shutting down, if you avoid the temptation to dip into that account "just this once". That does require having a little bit of a cash cushion, but a VC-funded company should be in a relatively good position in that regard.
If there's no personal liability, and the CEO is otherwise looking at bankruptcy, only ethics would force them to be honest with staff about being unable to make payroll. Employees would be out 1 pay at least, probably more, depending on how well the CEO can lie.
So make trading while insolvent a crime as it is in the UK - having a CEO who's panicking about becoming personally bankrupt is the last thing you want in a crisis.
We plan to treat the email addresses as people who might be interested in our product, and at some point we'll reach out to everyone who signed up and ask if they'd like to try it out.
If you know you don't want to try Periscope, but would like to read the eBook, by all means use the link above. ;)
In a perfect world, how would the charting in Periscope work? How would you want to go from getting 80% very fast, to going to 100%, in the same software?