822737 - As a developer I can view a list of transactions for my app

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P2)

Description

[krupa raj[:krupa]]

We need a way for developers to be able to view a list of all transactions on their paid app via devhub. This user story is supposed to be supported by Feb 14, 2013.

This is different from Manage Refunds page which only lists all transactions associated with refunds.

Comment 1

[Wil Clouser [:clouserw]]

This should list purchases, refunds, and pending refunds.  Tony is coming up with a design but it's simplistic - essentially just a <table>.  This is not a final page, I expect this will eventually live with our statistics pages.

Comment 2

[Tony Santos [:tsmuse]]

The more I looked at this and started sketching things out, the more I started wondering: why we can't use the existing stats page templates to show this information? The table at the bottom of the pages would need to be a 3 column table instead of 2 (Date, Transaction ID, Price) but the data would work well in this format. Am I missing a reason why this isn't what we're doing, and if so where do we see this new page existing if not in the Stats section?

Comment 3

[Wil Clouser [:clouserw]]

There isn't a reason to not use the stats layout.

Comment 4

[Tony Santos [:tsmuse]]

Then my recommendation, for consistency's sake, would be to create two new stats pages, "Purchases" and "Refunds", and put the info in there. It seems like the best place for it to go.

Comment 5

[Wil Clouser [:clouserw]]

Separate pages?  If a purchase becomes a refund does it still show up under purchases?  If it's pending approval does it show up on both?  Would it be easier to have a single "transactions" page and differentiate with colors or +/-, etc.?

Comment 6

[Tony Santos [:tsmuse]]

In my mind it would make sense to have Purchases as a metric all on it's own, because someone still purchased the app even if they later asked for a refund. Giving the developers the granularity to do their own fancy metrics (which a lot of them do for apps on iOS and Android) with our raw data. It really comes down to how our users are using the stats. They can learn a lot about their marketing push and the popularity of the app if they can see the overall number of purchases made. They can see that they have a real problem if they can see a spike in the number of refunds issues and pending. I think it would work as a single page if we can graph  purchases vs refunds on the same graph, then the +/- in the table would probably work. I'd like to avoid just thinking of a refund as "removing one purchase" though, because the data at the more granular level tells a more useful story than just "Net Sales". Does that make sense? It was kinda stream of thought typing :p

Comment 7

[Wil Clouser [:clouserw]]

It makes sense.  We can do graphs on the same page.

Comment 8

[Tony Santos [:tsmuse]]

Cool, let me know if you need anything else from me, I think this is going to be a super useful stat for our dev users :)

Comment 9

[Wil Clouser [:clouserw]]

Ok.  -> Andy for stats page backend.  Davor can help too.

Comment 10

[krupa raj[:krupa]]

Do we plan to show details related to every transaction? I think of stats as information over time. Developers will find a tabular list of transactions as it happened with related details (transaction id, transaction status etc) useful. Will the stats page include this?

Comment 11

[Tony Santos [:tsmuse]]

The other stats pages have a table under the graph, will the existing template allow for that detailed tabular data? That's where it should go. I agree it should be in the format of Transaction ID, Status, Transaction Type(Purchase, Refund) to be really useful. 

The stats section is the most logical place in the existing IA to put this kind of data, as stats shouldn't be just graphs of data plotted against time and summaries of things, but any descriptive data about the app's performance in the marketplace(downloads, installs, purchases,refunds, complaints, etc).

Comment 12

[Wil Clouser [:clouserw]]

Yes, we'll have a <table> under the graph.  Also the standard exporting options.

Comment 14

[Andy McKay]

Kevin already did a lot of this work in the past, in a slightly different way, showing the total transactions per day for the whole app. It can break out inapp payments and refunds.

Here's an example full of zeros ;) http://cl.ly/image/2M2z2P0o261t

So the graph to be useful would show the overall stats per grouping (day, week, month) and the table underneath would have to show each transaction (as opposed to the days value). I've got a few issues with this:

1) It's going to be prohibitively slow and expensive to show all the transactions for a period in that table. We allow up to 365 days of stats, that could be an awful lot of transactions.

2) The architecture right now summarizes the data into ES and send that to the pages, so this would be mean a complete rewrite of the stats pages again to send: summary data and the actual full transaction data.

3) I don't think we should be conflating showing overall sales data or volumes (something someone might want to make public) with something that should not be public (the individual transactions).

I think that showing a graph is useful, but confused on the plans here. I would propose:

1) Leaving the stats pages that Kevin did pretty much alone with a few clean ups and tweaks.

2) Adding a link to the bottom table on the stats pages, for each day. That will link will take you to a table (or open up a modal or something) that lists each transaction for that day.

3) Adding in a page that lets developers browse, filter transactions, search for a particular transaction id etc. and end up at a simple list of all those transactions.

4) A new stats page that shows purchases, chargebacks and refunds on the same page.

Comment 15

[Wil Clouser [:clouserw]]

In reply to comment 14, #3 ("Adding in a page that lets developers browse, filter transactions, search for a particular transaction id etc. and end up at a simple list of all those transactions.") is all this bug is about.  If adding a graph is substantially more work, let's not do it.  I may have misguided us into using stats pages and confused the issue.

All we want is a paginated list of transactions - we can add features later.

Comment 16

[Andy McKay]

kevin rocked this out and seems to be working great:

https://marketplace-dev.allizom.org/developers/transactions/

It's behind a view-transactions waffle switch I just turned on for -dev.