简介旅游景点数据分析实战资源包聚焦“去哪儿”平台国庆期间旅游数据面向对数据分析与旅游业运营感兴趣的初学者和从业者。资源以Python脚本处理景区门票销量、各省份景点分布、星级比例等数据并输出可交互的HTML图表帮助读者掌握从数据清洗、统计分析到可视化呈现的完整流程。整套文件共7个包含5个HTML可视化页面、1个Excel原始数据表、1个Python分析脚本压缩包仅79KB轻量易用。目前已吸引1379人学习适合用在线数据复刻分析场景或为自己的项目提供参考。通过这份资料读者可以学习热力图、柱状图、饼状图等常见图表在旅游场景中的制作思路了解如何基于门票销售与景区等级数据进行业务洞察并借助脚本实现同类分析、支持运营决策。1. 旅游景点数据分析实战先想清楚用数据回答谁的问题一个景区运营负责人每天可能被问三次为什么这周客流比上周少了一成新上的夜游项目到底有没有人买单二次消费一直做不起来是价格问题还是动线问题在没有一套旅游景点数据分析体系之前答案是“感觉好像”“听导游说”“看停车场满了没有”。这套实战方案本质上要解决的就是把这些问题变成可以拆到天、拆到时段、拆到客群、拆到消费场景的数据回答。它做的事情并不玄学把票务系统、闸机日志、园内消费、天气节假日这些数据拉通统一口径后按一套指标去算再把结果落到日报和归因分析里。操作层面就是数据清洗、指标计算、维度拆解和可视化这四步不依赖特殊的平台一台笔记本跑 Python 就够。适合人群是景区运营和文旅行业的数据分析师以及想拿真实业务练手的新人后者既可以自己模拟数据也可以接一套现成的票务导出来练习。2. 旅游景点数据从哪来四种数据源和一份数据字典做景点数据分析第一步不是写代码是先把数据资产摸清楚。多数景区并不是没有数据而是数据散落在票务系统、闸机、餐饮 POS、停车系统、会员小程序里彼此字段不统一。常见的数据源有四类可用性和成本差异很大落地顺序应该是先内部后外部。2.1 四种数据源取舍内部业务数据优先外部数据补场景第一类是票务系统数据包含订单号、票种、价格、支付渠道、游玩日期这是客流分析的绝对主力。第二类是闸机和入园日志记录每个人什么时间入园、什么时间出场能算停留时长和分时客流。第三类是园内消费数据来自餐饮、零售、体验项目的 POS 或小程序订单。这三类都属于内部结构化数据字段干净、实时性好是必须优先打通的。第四类是外部公开数据包括天气、节假日安排、客源地城市维度的公开统计等。这类数据能解释“为什么今天客流波动”比如暴雨导致客流腰斩或者“隔壁城市开了个新乐园”这种竞争因素。常见做法是用气象部门公开接口按景区经纬度拉天气把节假日安排人工维护成一张日历表。OTA 平台信息也可以作为舆情参考但采集和合规成本高一般放二期再做。数据源典型字段主要用途风险点票务系统订单号、票种、价格、支付时间销量、收入、票种结构存在退票和未支付订单闸机日志入场时间、出场时间、通道号入园客流、停留时长重复刷票、设备时钟偏移园内消费 POS消费时间、项目、金额二次消费率、客单价现金消费漏记外部公开数据天气、节假日、客源地归因分析、预测站点距离景区过远内部数据通常以 CSV 或数据表形式导出字段可能不全但一定够用。第一优先级是把票务和闸机打通因为这两个能算出最核心的“入园人数”和“停留时长”。消费数据其次接入有了它才能回答“客单价为什么上不去”。2.2 字段口径统一日期、游客ID、项目、金额是四块地基同一个字段在四个系统里叫法不同是常态票务系统叫“游览日期”闸机日志叫“入场日期”POS 叫“消费日期”。如果把这三个字段直接当一列用后面每个分析都会带着口径的隐患。我会先把关键字段统一成一张数据字典宁可前期多花半天也不要后期反复返工。-- 统一后的核心表结构窄表格式便于分析 CREATE TABLE dwd_tour_visit ( ticket_no STRING COMMENT 票号唯一, order_no STRING COMMENT 订单号一个订单可含多张票, visitor_id STRING COMMENT 游客唯一标识脱敏后的手机号/身份证, play_date DATE COMMENT 游玩日期业务口径日期, sale_time TIMESTAMP COMMENT 售票时间, entry_time TIMESTAMP COMMENT 实际入园时间空值代表未核销, exit_time TIMESTAMP COMMENT 实际出场时间, ticket_type STRING COMMENT 票种成人/儿童/免票/年卡, visitor_origin STRING COMMENT 客源地城市, project_name STRING COMMENT 主游玩项目, pay_amount DECIMAL(10,2) COMMENT 本单实付金额 );字段口径确立上三个坑要在建模前就定好。第一个坑是“游客ID和订单ID混用”一个订单可能含多张票订单ID去重会漏掉同行的其他游客。第二个坑是“售票张数和入园人数混用”线上买了票但没来核销的不能计入客流。第三个坑是日期口径票务系统关注销售日期运营分析关注游玩日期周末活动复盘应该以游玩日期为准。提示先区分“订单维度”和“游客维度”。做收入分析按订单聚合做客流分析按人聚合两个模型别混在一个表里。3. 客流、消费、客群把景点分析拆成可落地的指标体系数据拉通后下一步是定义指标体系。旅游景点数据分析常用的方法是从流量、消费、客群三个切面建模对应回答“来了多少人、花了多少钱、都是什么人”。最怕的是每次分析现想指标今天看总收入明天看总客流口径不一致导致结论前后打架。3.1 流量指标客流、核销率、停留时长、热力时段第一个目标是回答“景区到底来了多少人”。日客流的准确算法是统计 entry_time 非空且已入园的游客去重数而不是统计售票量。核销率则是入园数除以售票数这个指标能暴露渠道问题线上卖了很多票但没人来可能是黄牛囤票也可能是出行当天天气劝退了游客。停留时长用 exit_time 减去 entry_time取中位数而不是平均数因为存在少量过夜游客会让均值失真。热力时段分析则是把入园时间按小时聚合画出一天内的双峰曲线比如上午十点和下午两点两个高峰。它直接决定检票口和保洁人员的排班也能定位“为什么上午排队三十分钟下午项目空转”。from datetime import timedelta daily_flow ( df[df[entry_time].notna()] .groupby(df[entry_time].dt.date) .agg( visitors(visitor_id, nunique), tickets_sold(ticket_no, count), ) ) daily_flow[checkin_rate] daily_flow[visitors] / daily_flow[tickets_sold]这里nunique是去重计数闸机数据里一个人多次入园只算一次。checkin_rate低于 70% 时就要检查渠道健康度高于 95% 则说明票务和入园基本一一对应数据可信度高。3.2 消费与客群指标客单价、二次消费率、复游率客流再大不产生消费就是“虚胖”。消费侧三个指标最关键客单价、二次消费率、复游率。客单价的分母是入园人数不是售票张数否则未核销的票会拉低单客价值做出错误的经营判断。二次消费率等于园内产生餐饮购物等消费的人数除以入园人数它衡量的不是花多少钱而是“多少人愿意在里面再掏钱包”。复游率是景区和百货零售最大的区别点用 visitor_id 在历史窗口内出现次数大于等于两次的人数占比来衡量。周边散客为主的景区复游率通常要做到 30% 以上纯观光型景区可能只有 10%。如果复游率和预期差距过大先复查 ID 口径游客每次线上购票可能是新注册账号需要先做手机号打通。3.3 维度拆解天、周、节假日、天气、客源地交叉才出结论总量指标只能暴露问题不能解释问题。数据分析的方法里最实用的一招是交叉拆解把同一个指标按不同维度切片。比如“本周末客流比上周末下降 12%”只看总量会得出悲观的结论拆到天气维度发现这周末下了雨再拆到项目维度发现室内项目客流反而涨了 20%结论就从“经营下滑”变成“天气带来的结构转移”。常见的维度切法有五组自然日和星期几用来剥离周期性节假日前中后用来做活动评估天气状况雨天、高温直接影响出行意愿客源地城市用来判断渠道投放的效果票种结构免票和年卡用户占比过大会降低收入分析的有效性。每个维度分析时至少要带一个对比基准比如同比上周同星期几而不是环比昨天。维度拆解要多写一个“所以呢”比如“外地游客占比 60%”不是结论后续动作才重要外地游客更倾向于下午到达、住一晚再走那么就应该把夜游产品和次日票做组合。只看占比不动脑写出来的报告就是数据搬运工。4. 用 Python 跑通旅游景点数据分析清洗、指标计算与可视化前面指标体系定完之后进入实操。以单景区每日百万行以内的日志数据为例用 pandas 完全够跑不需要一上来就上 Spark那样徒增维护成本。整个流程分三步清洗原始日志、计算核心指标、输出可视化报表。这也是 python 数据分析与可视化在文旅场景里的标准落地路径。4.1 清洗原始日志处理重复、缺失、异常时间戳拿到的原始日志基本都有脏数据同一个订单上报了两遍、部分游客没有客源地、入场时间晚于出场时间。清洗的目标不是“把数据变好看”而是让后续每个指标口径可解释。import pandas as pd import numpy as np df pd.read_csv( visit_logs.csv, parse_dates[sale_time, entry_time, exit_time], dtype{ticket_no: string, visitor_id: string, order_no: string}, ) # 一个订单可能包含多张票去重时要按票号游玩日期而不是按订单号 df df.drop_duplicates(subset[ticket_no, play_date], keepfirst) # 客源地为空的记录填充为未知保留下来用于总量统计 df[visitor_origin] df[visitor_origin].fillna(未知) # 入场时间早于游玩日期或出场时间早于入场时间视为设备或录入异常 mask_abnormal (df[entry_time] df[play_date]) | (df[exit_time] df[entry_time]) print(fabnormal rows: {mask_abnormal.sum()}) df df[~mask_abnormal].copy()逻辑说明dtype指定为字符串避免 ID 被读成科学计数法drop_duplicates用票号和游玩日期联合去重因为同一订单多张票本来就该保留异常时间用布尔掩码先打印数量再过滤不要直接删先确认是数据问题还是设备问题。参数说明里两个关键点keepfirst保留第一条适合票务系统重复上报场景parse_dates需要列名和 CSV 表头完全一致日期格式不标准时先to_datetime(..., errorscoerce)再处理缺失。注意这一步产出的清洗中间表建议另存一份后续指标口径变了可以回溯不用重新解析原文。4.2 计算核心指标客流、客单价、二次消费率、停留时长清洗完成后把指标公式落成可复用代码。下面这段按自然日聚合出四个核心指标直接输出成日报表的主干。daily ( df.groupby(df[entry_time].dt.date) .agg( visitors(visitor_id, nunique), revenue(pay_amount, sum), ) ) daily[per_capita] daily[revenue] / daily[visitors] # 停留时长中位数单位分钟 df[stay_seconds] (df[exit_time] - df[entry_time]).dt.total_seconds() daily[stay_minutes] ( df.groupby(df[entry_time].dt.date)[stay_seconds].median() / 60 ) # 园内消费金额大于0视为产生二消分母是实际入园人数 inner_spenders ( df[df[pay_amount] 0] .groupby(df[entry_time].dt.date)[visitor_id] .nunique() ) daily[spend_rate] inner_spenders / daily[visitors] * 100逻辑说明visitors用nunique而不是count因为同一个人一天内可能多次入园多次出场revenue直接对支付金额求和退票在清洗阶段已经处理为负值记录时需要先聚合抵消。客单价用总收入除以实际入园人数反映的是“每个进园的人贡献了多少收入”。参数说明停留时长用中位数median而不是均值因为过夜游客会把均值拉高到十几个小时中位数更能代表普通游客体验pay_amount 0的判断默认免费项目不会产生金额记录如果系统里存在 0 元消费单要先把这类单子排除否则会虚增二次消费率。4.3 可视化把流量曲线和消费结构放进一张报表指标算完不算结束还要让人一眼看懂。一份合格的可视化至少要包含三张图日客流柱状图、客单价折线图、分时热力柱状图。import matplotlib.pyplot as plt fig, ax1 plt.subplots(figsize(12, 5)) ax1.bar(daily.index, daily[visitors], color#4C72B0, labeldaily visitors) ax1.set_ylabel(visitors, color#4C72B0) ax1.tick_params(axisy, labelcolor#4C72B0) ax2 ax1.twinx() ax2.plot(daily.index, daily[per_capita], color#C44E52, markero, labelper capita) ax2.set_ylabel(per capita (CNY), color#C44E52) ax2.tick_params(axisy, labelcolor#C44E52) fig.autofmt_xdate(rotation45) plt.tight_layout() plt.savefig(daily_kpi.png, dpi150)逻辑说明双轴图把“量”和“值”放在同一时间轴上对比客流看柱状、客单价看折线能快速发现“客流涨了但消费没跟上”的背离信号。曲线用twinx()创建右侧坐标轴注意两个轴的颜色要和图形元素对应。参数说明savefig代替show是因为日报要跑批后自动存档不能弹窗卡住dpi150兼顾清晰度和文件体积autofmt_xdate让日期标签斜排避免挤在一起。分时热力分析同样用这个方法把entry_time.dt.hour作为聚合键就能画出高峰时段曲线。整套 python 数据分析与可视化做下来就是数据接入、指标计算、图形输出这三步反复迭代和教科书案例的区别在于你要用自己的口径和脏数据去磨。如果数据量到了千万行以上单机 pandas 会明显吃力这时候再迁到 Hive 或 Spark 上做同样的清洗和聚合逻辑属于后话单景区前期基本用不上。5. 旅游景点数据分析避坑手册四个高频翻车现场这个标题下的方案我落地过不止一次每次踩坑的位置高度重合。整理四个最容易翻车的场景现象和原因都来自真实反馈不是理论推导。5.1 客流翻倍同一人多渠道入园被重复计数现象日报客流比闸机现场计数高出近一倍运营团队质疑数据可信度。原因有两层一是票务系统和年卡系统的游客 ID 是两套编码同一个游客买了票又用年卡入园被记为两个人二是纸质票和电子票共用同一通道闸机事件和售票记录没有做关联。解决清洗阶段先把 visitor_id 通过手机号脱敏字段做统一映射去重逻辑按“闸机实际入场事件”而非“售票记录”来算。如果两个系统暂时无法打通至少按身份证后四位加入场时间分钟数做临时关联键。5.2 客单价虚高分母用错导致数值失真现象人均消费算出来是三百多元现场调查却发现大部分游客只买瓶水。原因是分母用了售出票数其中包含大量未核销团票和赠票而园内消费只发生在实际入园的游客身上分母被低估客单价自然虚高。解决客单价的唯一分母口径是实际入园人数entry_time 非空的游客去重数。团票、免票在数据里要单独标记分析收入结构时和散客分开看否则团客的低消费会把整体客单价拉低掩盖散客的真实支付意愿。5.3 停留时长出现负数和极端值现象停留时长最小值是负数最大值超过 48 小时平均时长完全不能用。原因闸机设备离线后补传数据入场出场时间顺序错乱还有部分游客出场时走的是年卡专属通道没有和入场记录配对。解决清洗时把所有 exit_time 小于等于 entry_time 的记录剔除超过景区最大营业时长通常设为 18 小时的记录也剔除因为大概率是隔天补传。更稳的做法是输出一张“异常记录率日报”如果哪天异常率超过 1%先查设备再做分析否则带着脏数据出的图全是错的。5.4 天气数据错位用了城市站点而不是景区站点现象分析显示某天大雨客流下降但数据里当天天气是晴天归因结论完全反了。原因气象数据取的是城市中心站景区在郊区山区局部天气差异极大还有小时级降水数据没有按日期聚合凌晨下雨被算到白天。解决建立一张“景区最近气象站点映射表”记录景区的经纬度和最近站点编号按字段关联降水类指标用 24 小时累计值温度用白天时段均值而不是取全天均值。天气是归因分析里最常用也最容易出错的维度宁可多花两小时核站也不要拿错数据做结论。6. 从报表到归因与预测旅游景点数据分析的进阶路径如果日报已经稳定跑通下一步就是把数据从“事后复盘”升级成“事前预判”。我的做法是先做预测再做归因。预测不一定用复杂模型结构化数据加机器学习的经典组合就够用。先把日期特征和天气特征组装起来构造训练集用随机森林回归预测未来七天客流。from sklearn.ensemble import RandomForestRegressor features [is_holiday, is_weekend, temp_high, rain_mm, prev_7_avg_flow] model RandomForestRegressor(n_estimators200, min_samples_leaf5, random_state42) model.fit(X_train, y_train) y_pred model.predict(X_test)参数说明min_samples_leaf5限制叶子节点最小样本数防止模型对节假日极端值过拟合n_estimators200在这个数据量级下足够稳定再大只会增加训练时间。预测结果回填到日报里实际值与预测值偏差超过 20% 就自动标红运营团队只需盯异常不需要每天都重新拍脑袋定目标。归因层面我吃过一次亏只看客流总量增长就归功于新上的营销活动后来拆分发现增长全部来自免票儿童带动家庭票活动转化率其实很低。从那以后任何结论必须至少拆到客群和项目两个维度交叉验证。预测同样如此模型不会告诉你为什么它只给信号解释信号还是要靠人和维度拆解。这个方向的进阶顺序很清晰先把指标体系跑稳再上预测预警最后逐步加入实时数据做动态调度。希望帮到你少走我走过的弯路。本文还有配套的精品资源点击获取