I've been a PM for over 6 years now and made the transition from an IT Dev Manager. I basically made the case that I understood the product, its target customer, and the value for the company. If you can master that, you're set. Everyone has ideas for new features, but PM's balance the needs of the customer with cost to develop and value to the company. This requires that you understand the market, your competitors, and your customers. The PMs that thrive have mastered this, but more importantly, they've learned how to get the team to work together efficiently -- both the technical side as well as the management side (cutting through the political and management BS). If you are interested in becoming a product manager, know what skills you bring to the table. If you are a developer, you bring strong analytical and technical skills as well as an understanding of the technical effort required to bring a new feature to market. Probably the best skill you would need to demonstrate is judgment: which feature would bring the most value for the least cost. And then showing how would you prioritize the roadmap of features after that.
Google Analytics is used primarily for internal reporting and analysis. bscorecardresearch is part of ComScore, which is a third-party reporting company. Advertisers often require publishers to provide third-party reports for traffic so that they can validate the ad campaign numbers that the publisher reports. Chartbeat and others can provide supplemental reporting to a publisher if they think that there are gaps with what Google Analytics provides.
Someone on reddit asked why this isn't considered an Antitrust violation (akin to Microsoft). An anti-trust lawyer explained why, but better yet, provided more context around the merger. It appears that this will ultimately go through, given the climate of the current administration and the dynamics of the merger.
Here is the anti-trust lawyer's explanation:
Antitrust lawyer here.
For one, we're talking about different antitrust issues. Broadly speaking, the antitrust laws prohibit (1) concerted action that harms competition, like price fixing cartels; (2) unilateral action by a monopolist that harms competition; and (3) mergers and acquisitions that significantly diminish competition.
Microsoft was alleged to have used its position as a monopolist to undermine competition. That's (2) above. Typically, monopolization entails an element of foulplay. Achieving or maintaining a monopoly through normal, reasonable business practices is not illegal.
Comcast and TWC are proposing to merge. That's (3) above. When evaluating a merger, the DOJ looks at whether the companies directly compete in any markets, and whether the merger is likely to reduce competition in those markets.
Comcast and TWC claim that they do not directly compete. That's true, but there's more to the story. Comcast and TWC will point out that cable systems are "natural monopolies" -- it costs a lot to lay cable, and where one company has already laid cable in a given area, it enjoys a huge cost advantage over other would-be competitors, who would have to lay their own cable to compete.
But on the other hand, Comcast and its rivals have also done some dubious stuff in the past that has led to the current competitive landscape. For example, Comcast, TWC, and others have engaged in a number of anticompetitive deals, such as geographic market allocation and customer swapping, to create large regional monopolies. These deals themselves arguably violate the antitrust laws -- see (1) above -- and indeed are the subject of ongoing litigation. But unfortunately, the DOJ most likely would not take this background into account when evaluating the likely effect of the merger on competition.
So when Comcast and TWC say that the merger will not reduce competition because they do not currently compete, that is in part due to the fact that they have already agreed not to compete. It's like two members of a price fixing cartel saying that merging would not reduce competition because, hey, they aren't competing anyway.
We don't know yet whether the DOJ will challenge the merger. The Obama DOJ has been decent in this area; they challenged the AT&T/T-Mobile merger and US Air/American Airlines merger. But neither of those cases played out -- the FCC killed AT&T/T-Mobile, and the DOJ caved once politicians began pressuring the agency to let US Air/American Airlines go through.
Given that Comcast is so well connected in Washington, and in light of the potential difficulties in establishing that the merger will actually reduce competition, I expect that the DOJ will approve the Comcast/TWC merger, subject to certain concessions.
Politics is a core issue when it comes to antitrust enforcement. In fact, I don't think the Obama DOJ would sue Microsoft today. Clinton's DOJ was a bit more aggressive in this area.
As someone who works for a major e-commerce site, I am often the one who has the most influence when it comes time to decide which testing method to adopt. Multi-armed Bandit testing can be good, just as standard A/B testing can be good. But the factor which trumps all of these are the total costs of testing (and the return on investment to the business). One must consider the following before undertaking any of these testing methods:
1. Implementation Costs - How much time will it take to implement the testing code? Some tests are easier to implement than others.
2. Maintenance Costs - How much time will it cost to maintain the test for the duration of the testing period? We've ignored this in the past only to realize on occasion that implementation introduces bugs which incur cost and can be disruptive.
3. Opportunity Costs - What is the cost of doing the test versus not doing the test? Consider setup time, analysis, and final implementation.
After going through a few tests now, we have a pretty good sense for what the total cost to the business is. We don't really look at it as adopting one test method over the other, but instead rely upon the projected ROI to test this versus that, versus doing nothing.
If you've conducted multiple tests and "time to implement the testing code" is a major consideration, then you're doing it wrong. If ROI is also a major consideration, then again you're doing it wrong.
Seriously to add an email test right now at the company I'm contracting for takes 2 lines of code. One appears in the program that sends email and looks like:
$email_state_contact->ab_test_version("test_1234", {A => 1, B => 1});
where test is the name of a test, and 1234 is a ticket number to avoid accidental conflicts of test names. The other appears in a template and looks something like this:
I can imagine a number of situations where the implementation is significantly more complex. While ideally A/B tests should be looking at relatively small changes, where each change is independent, many times people are making profoundly larger changes.
If you are testing the conversion rate in shopping carts, and the changes involves drastic redesigns of the flow through the shopping cart process, that could be a serious technological difference and requires substantial time to implement.
Not every test is as easy as changing the copy on an email.
Even if you're making larger and more complex changes, the overhead of your testing methodology remains the same. That is how you measure things should be a fixed (small) effort, The cost of building the test is whatever the test is.
In other words multi-armed bandit versus A/B test is something that you shouldn't be deciding based on the effort of the testing methodology.
That's a fair assessment. Akamai isn't really ideal for startups (from a cost standpoint), but once a startup has gained traction in the market and is looking to scale (or optimize performance), you can't beat Akamai. Code optimization will only get you so far. Akamai's service will do things like find the shortest path (which cuts down on latency) and all sorts of other things upstream/downstream. Those things sound small, but have a huge impact to your site's performance.
Apple should just sell the cables at cost (or near-cost) so that they maximize adoption of Thunderbolt. They can make money elsewhere and therefore afford not to profit, but they would gain better adoption in the long-run.
I wonder if it's possible to increase the speeds, without having to revise the chip-on-the-motherboard. Then users could upgrade their speeds by buying a new "faster" cable.
It looks like that's what they're doing (unless I misinterpreted this quote):
> Our telecom source noted that Intel made an unusual choice in also using active cabling for future optical-based iterations of Thunderbolt. Passive cabling is more common, but active cabling could offer some advantages. For one, active cables could combine fiber optics with electrical cabling for power transmission. Another good reason to use active optical cables, according to our source, "is that your current electrical ports can be forward compatible with future optical cables."
Those future optical cables won't be faster. Some people are optimistically misinterpreting Intel and thinking that they'll get 100 Gbps out of existing Thunderbolt ports, which is definitely not true — those ports are already going as fast as they can. Optical only gives you longer distance.
Another factor, related to bad data, would be price fraud. Fraudsters deliberately price a "vehicle" low (relative to mileage) in order to attract a high number of people. They know that only a small percentage will take the bait and send cash up front for a vehicle that he doesn't intend to sell, so he wants to make sure to get the highest number of people to respond to the listing. It's a classic buyer-beware scenario, so just keep that in mind as you see good deals in the "better" zone.
