Product ideas | Community
Skip to main content

Filter by idea status

10000 Ideas

jdonleyNew Participant

Data Warehouse - Increase / Fix Report API FunctionalityNew

Data Warehouse had a dedicated DataWarehouse API v1.3 but has been deprecated and my understanding is due to be shelved completely sometime this year. Though, it was lacking in the features I desired anyway (read on)The current standard is to use Report.Queue  to request a Data Warehouse report. 1) DOCUMENTATION UPDATE - The reportDescription listing documentation does not show how to specify ftp info for ftp delivery.  I was able to piece this together together because the example Object output by the API Explorer includes it, and it's relatively straight forward - mostly.  Specific values I was also able to piece together from the v1.3 DataWarehouse.Request listing (not the same property names but still).  Also, the v1.4 Data Warehouse Reports documentation just gives a quick comment about referencing the Report.ReportQueue method - which doesn't even exist anymore (it points to a 404 page, and the method itself was deprecated from v1.4).  So.. this should point to the Report.Queue method, but now we've come full circle with no info detailing Data Warehouse API usage for v1.4 Report API. Can someone please update the v1.4 documentation to include Data Warehouse report pull usage?2) FEATURE REQUEST - Report.Queue only lets you make a one time report request to Data Warehouse.  It does not let you include/configure anything for scheduling a repeated/ongoing report export like you can in the interface.  Well, it's not documented, anyways.  Not even in the v1.3 version.  This is a very big pain point for several of my clients and it would be super nice if it could be added.3) FEATURE REQUEST - Also, there is no way to retrieve information about Data Warehouse reports currently in the Data Warehouse queue.  I would like to be able to make an API request to get a listing of all Data Warehouse reports in the Data Warehouse queue, whether it be one time jobs still in the queue, history of completed jobs, and - most importantly (to me, anyways) - list of Reports on an ongoing / repeating schedule.  Maybe a method to pull a list of all id/names and then another method to pull config data based on id? That would be super nice and helpful.4) FEATURE REQUEST - And following that train of thought, it would also be nice to have API methods that allow me to update configuration or cancel/delete report jobs.5) BUG FIX (?) - In the Data Warehouse interface, I am able to choose Marketing Channel Last Touch Instances as a metric. It is there. I can select it, and it shows up in the exported FTP. I can provide screenshot evidence.  But it is not available via an API pull.  I have tried generic "instances" - says this metric is not available for data warehouse pulls (what??). One trick I have found over time to get around lack of documentation is to inspect html elements on pages within the Adobe Analytics interface.  I can do this in the Data Warehouse interface screen and in the html code "@marketingchannellasttouchinstances" - does not work (with and without the leading @ sign).  I've tried many variations of that. I've tried a Report.GetMetrics API call and nothing relevant is listed, though I saw a lot of other "instance" type metrics for other elements listed with their "instance" prefix, followed by their element id, so I tried "instanceslasttouchchanneldetail"  - no joy.  I tried all kinds of combinations of these words. Reordered, added. Removed. No joy all around.  But clearly this is available as a metric within the DW interface, so it MUST be a metric available on the back-end, and the API just isn't aware of it.  Or more accurately, the Report.Queue API's data validator isn't aware of it so maybe any one those things does in fact work but is getting blocked by the API's validator because the whitelist is not comprehensive.  Whatever the case may be, can someone please add this, and while you're at it, do an audit to sync up what is available within the DW interface vs. the API!6) BUG FIX (?) - I created a segment in segment manager.  In the Data Warehouse interface the segment is available. I can schedule a DW report within the interface using the segment. I receive the exported report and the data accurately reflects what I expect.  I have verified this thoroughly.  I attempt to throw the same segment into the Report.Queue API call for Data Warehouse, and I am sent a blank file with nothing but the column header row.  The DW API request sends me all the data in the world without the segment thrown into the mix, but returns me nothing when I add it.  Scheduling the same exact thing within the DW interface sends me data.  Yes, I have triple checked that the segment id is correct. I even used that inspect html element trick I mentioned earlier to verify it both within the segment manager AND within the DW interface.  All shiny.  So this seems to me that there is some kind of bug with applying segments to Report.Queue API calls for data warehouse. Sidenote : segments applied to regular Adobe Analytics reports work just fine for me; I do those all day long for other projects. So whatever is wrong with segments via API call, I think it is Data Warehouse specific ("source":"warehouse"). Can someone please look into and fix this?

Antti_KoNew Participant

Workspace: breakdown by position should be turned on as defaultNew

Nowadays, we can breakdown by position and this is great. However, I just can’t understand why this setting is turned off by default? Aren’t we always try to breakdown by position = give me TOP something. If there are special cases, we can always manually choose to filter SEO traffic if for some reason we want to always breakdown by SEO in last touch channels, or we could manually filter certain products if we want to week by week just to follow certain products. To me these are special situations and manual work would be just fine, but for my common sense it doesn’t make any sense that breakdowns aren’t ordered by position as default. I’ll give one example with screenshots.(Edit: Seems I can add only one screenshot, so I added combination of 5 and 6) 1) Added entries as metric and week as dimension. Time range is last 2 full weeks. Breakdown by position disabled by default.2) Added last touch channel as breakdown for weeks. Breakdown by position still disabled by default.3) Ok, I’ll check breakdown by position. I tested this separately and noticed you need to check this option if you want to see last touchchannels as breakdowns for new weeks when time moves on. This is alone good reason why this option should be enabled by default. Hard to understand why you wouldn’t want those breakdowns to continue. 4) Just to double-check, every dimension has its own ”breakdown by position” option, so these aren’t enabled for last touch channels, I just enabled these for week dimension.5) Week just moved on to another Monday morning and we have new week starting from 27th of February. There is a breakdown for last touch channel, I guess this due the fact I enabled breakdown by position for the week dimension. However, now it shows Natural Search as number 1 and that is not true, I mean that is not my best traffic sources for that week.6) Just to double-check I modified the filtering options and now I can see that direct traffic is the best traffic sources for that week. I could have done my analysis totally wrong if I didn’t realize to put that setting on for every single dimension = Time-consuming. Not sure did I do everything correctly, I tried… but please comment If I did or understood something wrong. If I’m correct, then I just can’t understand why Adobe (or any other user) would want this to work like this? You should always want to see your TOP breakdowns, and if there are moments you want to see something else then you can do manual filtering or something. Ps. Again, we would like the option (as admins at least) to choose our own default settings, and there is idea request for that one too. But even if we could do that, I still would want this breakdown by position feature to be by position as default.